Works, decent structure... less opinionated, similar to bootstrap, bulma or any number of other CSS libraries.
Kind of would like to see one of these css library/frameworks much more opinionated. For example, just make the baseline button as well as submit/reset form types the default button composition (no btn class needed). Header elements should also be styled by default. Similar for stylized radio/checkbox items...
<label><input type="radio" .../><span>text</span></label>
As a convention is enough to custom style in modern browser with the nearest neighbor, the label wrapping the input will cause the label to work without the need of a "for" attribute.
The class soup just gets a bit weary after a while, and largely unnecessary.
For most of what I've been working on lately, the API is a slice from the main application domain... ex: /api will reverse-proxy to the api service, other routes will serve from the ui static files.
No CORS at all, so only the service domain can be used in a browser.
This can be done with nginx, caddy, kubernetes entry, or even in IIS via the ARR extension.
The use of theme in the makeStyles isn't really done right... should use main color from a palette and a contrast color for the text... you can add multiple palettes to your theme injection. then, you only need to specify the palette to use for the button. As for the spacing, you shouldn't hard-code px, you should use either relative to the font (em, etc) or use theme.spacing() method to generate the spacing string.
Instead of `padding: "20px 10px"`
use `padding: theme.spacing(2, 1)`
If you take the time to actually read through the documentation for material-ui, there is a lot in the box to use. Overriding styles is not the best idea and material-ui is meant for creating applications, the more you lean on the component library, the less friction you will see in your application.
You should mount your theme under your state management (redux), this way you can have your theme driven from state (dark mode, primary/secondary colors, etc) or otherwise by configuration. If you leverage the ThemeProvider with makeStyles or withStyles, it will absolutely apply globally... you can extend the theme object for your provider by adding additional attributes and palettes beyond primary/secondary... it's only that the main components expect primary/secondary, you can add additional features and leverage them throughout your application.
One of the things I wish that were done differently in mongo, is that is supported a sharding + replication scheme similar to how many other systems do such as ElasticSearch, Cassandra, RethinkDB etc. For that matter, I really wish RethinkDB had as much support as mongo.
Also, I've been in a situation where the network failed between all nodes (major Azure outtage a few years ago) where nodes were up/down several times over a few hours and the databases would no longer sync up at all... That was not fun in any way shape or form. In the end, it was mirrored data from the primary dbms, and I just rebuilt the cluster and cleared the replication records in the source database.
If you're doing replication with mongodb, understand how to take the nodes out and re-create a cluster from a single node.
Mostly agreed... I think of deno more as an alternative major change (much like python 2/3 split). Not sure if deno will take over, there are a lot of places that should be shorn up... one of the big ones for me is a consistent ffi library, and while node-ffi package works, it's not exactly transparent and imo should be in the box.
Deno is pretty solid in most other areas though... only native modules need a bit more considerations for the use cases without a good alternative. That's a little outside my comfort zone as a developer, but there's work in progress for all of this.
My only curiosity is if OvermindJS can grow to larger state objects... with Redux, you can slice your state up into separate sub-reducers per property on the state object.
Also, I prefer the hooks to the hoc at this point.
Works, decent structure... less opinionated, similar to bootstrap, bulma or any number of other CSS libraries. Kind of would like to see one of these css library/frameworks much more opinionated. For example, just make the baseline button as well as submit/reset form types the default button composition (no btn class needed). Header elements should also be styled by default. Similar for stylized radio/checkbox items... <label><input type="radio" .../><span>text</span></label> As a convention is enough to custom style in modern browser with the nearest neighbor, the label wrapping the input will cause the label to work without the need of a "for" attribute. The class soup just gets a bit weary after a while, and largely unnecessary.