React and Material UI
-
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service -
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection ServiceMarc Clifton wrote:
Pretty much despise both.
Well, I agree with you in regards to Material UI. Or any JS "CSS" framework that does more harm than good. I don't know why, but devs will do anything to avoid learning CSS. IMO they should go be a farmer if they hate CSS that much. But it gets even worse when you add a JS layer for CSS on top it - your styles run much slower. Don't get me started on that. But, React is awesome. Granted, sometimes it seems like every release changes things, but it's still a great framework. Any issues you got from it, I can promise is a result of not fully understanding the JS way of life. Which is, let's just call it "different". :)
Marc Clifton wrote:
React: Really, no two-way data binding?
I think you're confusing React with Redux here, but unidirectional data binding is a good thing. Two-way data binding is slow and meant for people who don't want to learn. Redux was originally inspired by Facebook's Flux, which also used a concept of unidirectional data binding. React itself works no different than any other component-based architecture, including native web components (which was inspired by React).
Marc Clifton wrote:
And then, there's the "old" way of using React, with classes and super(props, state and the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech.
The old way isn't the OOP way. The old way was using lifecycle methods. They tried the OOP way. The community rejected it. They moved to hooks. Hooks will be supercceded btw, but that's a different story for a different day. But, make no mistake the vast, vast majority of hardcore JS devs prefer a functional paradigm. Clearly you don't, so look inward if you hate change that much. :laugh: That being said, there's absolutely nothing preventing you from using the OOP way Marc. It's still there. Come on Marc, do better than junior-type rants.
Marc Clifton wrote:
And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific
-
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection ServiceMarc Clifton wrote:
, but half the time I have to extend the "props" with React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out
Also, you don't have to do property chaining for everything. But, you should use props, as components are meant to be modular. Props shouldn't have to chain often though. That being said, there is a time and place to use shared data that's not global. For instance, [Sharing State Between Components – React](https://react.dev/learn/sharing-state-between-components), but that's not a chain in the traditional sense. And if by pubsub, you mean the older context api, I can agree that's a bit wonky, but nothing is stopping you from not using contexts or the useContexts hook. Or just roll your own global state object, it's not that hard. Keep in mind though, relying on this too much is not much better than global variables. So, do better Marc.
Jeremy Falcon
-
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection ServiceAnd once last thing, HOCs is a concept borrowed from HOFs. I'll let you Google what HOFs are, but again this is a conversation of functional vs OOP paradigms. Can go into detail of the pros and cons if you can concede a blanket "OMG functional sucks because I'm not used to it" conversation is beneath us.
Jeremy Falcon
-
Marc Clifton wrote:
Pretty much despise both.
Well, I agree with you in regards to Material UI. Or any JS "CSS" framework that does more harm than good. I don't know why, but devs will do anything to avoid learning CSS. IMO they should go be a farmer if they hate CSS that much. But it gets even worse when you add a JS layer for CSS on top it - your styles run much slower. Don't get me started on that. But, React is awesome. Granted, sometimes it seems like every release changes things, but it's still a great framework. Any issues you got from it, I can promise is a result of not fully understanding the JS way of life. Which is, let's just call it "different". :)
Marc Clifton wrote:
React: Really, no two-way data binding?
I think you're confusing React with Redux here, but unidirectional data binding is a good thing. Two-way data binding is slow and meant for people who don't want to learn. Redux was originally inspired by Facebook's Flux, which also used a concept of unidirectional data binding. React itself works no different than any other component-based architecture, including native web components (which was inspired by React).
Marc Clifton wrote:
And then, there's the "old" way of using React, with classes and super(props, state and the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech.
The old way isn't the OOP way. The old way was using lifecycle methods. They tried the OOP way. The community rejected it. They moved to hooks. Hooks will be supercceded btw, but that's a different story for a different day. But, make no mistake the vast, vast majority of hardcore JS devs prefer a functional paradigm. Clearly you don't, so look inward if you hate change that much. :laugh: That being said, there's absolutely nothing preventing you from using the OOP way Marc. It's still there. Come on Marc, do better than junior-type rants.
Marc Clifton wrote:
And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific
Jeremy Falcon wrote:
Or any JS "CSS" framework that does more harm than good
I'll agree on you about avoiding things that do more harm than good. That's a fairly benign statement.
Jeremy Falcon wrote:
devs will do anything to avoid learning CSS.
Do they, though? I'm a strong proponent for using 'standard' frameworks, where 'standard' means 'what everyone else is using'. It's not because it's the best or fastest or most efficient, but because there's a huge amount of help for you and your junior dev, constant improvements and lots of eyeballs to spot issues (and hopefully a lot of pressure to get those issues addressed). I use Bootstrap where I can. I don't particularly like it, but it's solid, stable, forces me to not overcomplicate things, and I know any dev can come along and muck around with it if they needed. Even so, I really, really need to understand CSS if I'm going to work with it safely and I'm still to this day learning stuff about CSS that I never imagined.
cheers Chris Maunder
-
And once last thing, HOCs is a concept borrowed from HOFs. I'll let you Google what HOFs are, but again this is a conversation of functional vs OOP paradigms. Can go into detail of the pros and cons if you can concede a blanket "OMG functional sucks because I'm not used to it" conversation is beneath us.
Jeremy Falcon
-
Marc Clifton wrote:
Pretty much despise both.
Well, I agree with you in regards to Material UI. Or any JS "CSS" framework that does more harm than good. I don't know why, but devs will do anything to avoid learning CSS. IMO they should go be a farmer if they hate CSS that much. But it gets even worse when you add a JS layer for CSS on top it - your styles run much slower. Don't get me started on that. But, React is awesome. Granted, sometimes it seems like every release changes things, but it's still a great framework. Any issues you got from it, I can promise is a result of not fully understanding the JS way of life. Which is, let's just call it "different". :)
Marc Clifton wrote:
React: Really, no two-way data binding?
I think you're confusing React with Redux here, but unidirectional data binding is a good thing. Two-way data binding is slow and meant for people who don't want to learn. Redux was originally inspired by Facebook's Flux, which also used a concept of unidirectional data binding. React itself works no different than any other component-based architecture, including native web components (which was inspired by React).
Marc Clifton wrote:
And then, there's the "old" way of using React, with classes and super(props, state and the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech.
The old way isn't the OOP way. The old way was using lifecycle methods. They tried the OOP way. The community rejected it. They moved to hooks. Hooks will be supercceded btw, but that's a different story for a different day. But, make no mistake the vast, vast majority of hardcore JS devs prefer a functional paradigm. Clearly you don't, so look inward if you hate change that much. :laugh: That being said, there's absolutely nothing preventing you from using the OOP way Marc. It's still there. Come on Marc, do better than junior-type rants.
Marc Clifton wrote:
And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific
Hah, thank you for the great response! I'm learning and given that SO is pretty much my only source for "why isn't this working", I'm bound to get bad information. I should probably take a course in React. So again, thank you for pushing me to learn more!
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity Framework -
Did you miss the opening part of Mark's post where he specifically stated
Quote:
Disclaimer: Rants of noob working with React and Material UI.
Hogan
Fair enough, but ya know...
Jeremy Falcon
-
Jeremy Falcon wrote:
Or any JS "CSS" framework that does more harm than good
I'll agree on you about avoiding things that do more harm than good. That's a fairly benign statement.
Jeremy Falcon wrote:
devs will do anything to avoid learning CSS.
Do they, though? I'm a strong proponent for using 'standard' frameworks, where 'standard' means 'what everyone else is using'. It's not because it's the best or fastest or most efficient, but because there's a huge amount of help for you and your junior dev, constant improvements and lots of eyeballs to spot issues (and hopefully a lot of pressure to get those issues addressed). I use Bootstrap where I can. I don't particularly like it, but it's solid, stable, forces me to not overcomplicate things, and I know any dev can come along and muck around with it if they needed. Even so, I really, really need to understand CSS if I'm going to work with it safely and I'm still to this day learning stuff about CSS that I never imagined.
cheers Chris Maunder
Chris Maunder wrote:
Do they, though?
That's been my experience. A FE dev will claim to know CSS because they learned what a selector is, but then say specificity is complicated or JS CSS is better because it can be modularized (so can vanilla CSS, SCSS, etc.). They don't know when to use em vs rem, etc. Couldn't do a basic responsive layout. And sooooo many pixel values everywhere. :laugh:
Chris Maunder wrote:
I use Bootstrap where I can. I don't particularly like it, but it's solid, stable, forces me to not overcomplicate things, and I know any dev can come along and muck around with it if they needed. Even so, I really, really need to understand CSS if I'm going to work with it safely and I'm still to this day learning stuff about CSS that I never imagined.
I'm actually a fan of Bootstrap, as far as frameworks go. I'm a purest at heart, so in a perfect world I think cluttering up the DOM with declarative type class names everywhere is pure chaos, but IMO frameworks like Bootstrap are 1,000 times better than ones like Material. Bootstrap actually uses CSS where Material and the like have a JS execution layer that's inherently slower to render. It wants to turn CSS into JS... for zero gain. And I totally agree there's a time and place for things, not reinvent the wheel, etc. Like with Bootstrap. I've used on projects and in some cases would recommend it. But, I do think a dev should know how to do things without a framework at all, for the enterprise. Because when something goes wrong and everyone's watching, home dude or dudette needs to debug.
Jeremy Falcon
-
Hah, thank you for the great response! I'm learning and given that SO is pretty much my only source for "why isn't this working", I'm bound to get bad information. I should probably take a course in React. So again, thank you for pushing me to learn more!
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity FrameworkMarc Clifton wrote:
I'm bound to get bad information.
As much as I defend JS on CP, I gotta agree with you there. There's so much garbage info online. Way too much. Everybody and their grandmother uses JavaScript and claims to "experts". I'd probably feel the same way if starting fresh. And don't get me wrong, React isn't perfect. For one, the library is large to include. For two, it does seem like crap changes every other release. And it's been proven there are quicker ways to render than the virtual DOM. But, it's still super-fast compared to most frameworks. And as far as frameworks goes, it's way more modular than Angular for instance, so you only have to use it for what you intend to... rendering. You don't to use the router for instance, if you don't like it. But, it's not perfect. It will force you into thinking about breaking down everything into components though... moreso than a framework like Angular (I've only used old Angular though, maybe that's different now). Given native web components are a thing now though, that's not inherently bad.
Jeremy Falcon
-
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service -
I hate Web programming - the Web is a total mess
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection ServiceHave you considered looking into Redux for state management? We use it at work and I tend to make use of it on personal projects where I need to do anything complex between components so that I can maintain that complexity within state. The downside is that it is another steepish "learning curve", the tutorials are good though - I found once I had everything wired up with Redux a lot of other complexities were solved for me although I am aware it's yet another thing to add and learn(I won't get started on Thunks which I have so far avoided on personal projects). Also, another thing :sigh:, TypeScript sits very nicely with React.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Disclaimer: Rants of noob working with React and Material UI. Pretty much despise both. Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling. React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with
React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code. And then, there's the "old" way of using React, with classes andsuper(props, stateand the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech. And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets theselectedIndexeven though I'm not setting it in the state! So any field that uses{this.state.foo}causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!" And don't even get me started on usingreact-routerwhich then requires (according to SO) that everything now be children ofHashRouterinstead ofBrowserRouterwhich means hashes in the URL's. I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service -
I hate Web programming - the Web is a total mess
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
