Very cool... would love to see a style method that works with material-ui and JSS... would just need a function that accepts a theme, and then use that theme combined with positional definitions `"& .subclass"` to target children... this way the styling can match material-ui while still keeping its' component structure... I haven't looked at the CSS or rendered markup to determine any of this, only know that it's possible.
edit: created feature request.
https://github.com/Adphorus/react-date-range/issues/347
One thing to note, is that with HTTP2+ if you can push many of the required baseline .mjs files to your client, or setup an appropriate manifest for offline caching it will dramatically improve performance. Having a request based model will mean much lower load times over slower/intermittent networks (phone/wireless).
I really do think that this approach is the future, even if I'm not sure how well this will integrate with the broader JS community in the near term. I also think there's maybe another year or two to flush out some adjacent utilities to help with initial load of projects like this into a browser. I hope that a packaging system (deliver zip or tarball to browser) gets traction and takes hold.
Something to note: Other than local/development, and even for testing, don't put your production configuration into .env files... either generate it from a template in your ci/cd pipeline, manually generate it and/or use the actual environment to specify said settings.
Another aside, I really tend to prefer the URI syntax for connection strings, this allows for a single setting to contain protocol, user, password, host, port, database and additional options. While it's a more complex string, it's fewer things that need to be set in terms of environment variables and secrets and the more applications/services you are setting up the more you will appreciate the convention.
This is just my $.02, but class-based models are just burdensome in practice and tends to come from a different mindset, usually those who are very experienced or comfortable with Java or C#. I'm not a hard liner either way, there are times where class syntax is incredibly useful with JS, usually where you need to bind context to events, however this is more of an exception to the rule so to speak and being pragmatic over purity. For most logic work, functional workflows will be easier to comprehend and maintain over time.
While you can use this approach, I find that in practice, it's generally better to use plain/simple objects without any magic, and use immutable function libraries against those plain objects (and/or arrays of plain objects) for workflows/pipelines. If you're using TypeScript, you can still do interface definitions for expected properties and the shape of said objects.
Once you go down the path of getters/setters you open yourself up to a level of mutation that's hard to account for in terms of testability and reliability.
JavaScript has a wonderful flexibility in terms of object construction with functional composition. And while not strictly a functional language with full immutability features, the closer you stick to these conceptually, the less variance and trouble you will have in practice.
This library seems to introduce its' own complete CSS instead of re-using the SCSS that Bootstrap from source offers.
Don't use bootstrap this way... It's *REALLY* easy to use Bootstrap's SCSS from source.. Include bootstrap as an npm dependency, have your scss file set whatever font/color settings you want to use, then include the scss from bootstrap proper.
Cool, but what does this really do/offer over react-redux's useSelector? I mean, you potentially have access outside of context, but you can do that with React's Context as well as Redux.
Really veers off-topic. Do you guys appreciate this kind of content? It seems to be higher quality than most similar content I see, usually very spammy, which is why I didn't just delete it.
Like too many articles, this conflates/confuses a couple of things... Material Design is the design guidelines by Google[1]. Material-UI[2] is a React library of components that implement Material Design.
That said, Material-UI is the single best component library, with React that I have ever used or experienced. In practical use, I will almost always defer to the design guideline and component defaults and/or examples and try to use the components with minimal modification. There are a *LOT* of components that follow the theming and it works great.
I will say some of the commercial (and free versions) of "templates" that use material-ui are very bad in terms of code structure and layout. They often break the approach setup in the framework (using a function for jss that receives the theme and adding additional properties to the injected theme).
1. https://material.io/
2. https://material-ui.com/