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/
Really like this library overall... while it may seem weird using abstractions for browser API use, the abstractions are clean and the use is really close to what one would hand-craft anyway.
While not a huge fan of TS, it takes a lot of extra work, and at the application level the effort isn't always worth it... I will say, as far as library support, it's been pretty valuable to the point where I've been considering moving anything I push to npm in the future being written in TS.
I usually have a dedicated API service for the front end that's more closely tied to the UI/UX, this may call other API's and services behind it, or the database directly. As a project grows, splitting and adding a primary API gateway may be more prudent.
Interesting... but should probably rely on defined and longer symbols over `^` and `#`... also, against using async decode since that stops this from being a drop in replacement for JSON.stringify/parse.