If you're wrapping the response from fetch for an error, I would suggest using
throw Object.assign(new Error("Fetch Error"), { response });
This gives you the full context instead of response.toString() as the error message.
Something I do in practice for my API endpoints is always return {result} or {error} from my API. An object where a root error can be checked against, or the result... This way I can have a very consistent handler, which is usually a wrapper around fetch as I'm not currently supporting any non-green browsers and fetch has been around for long enough now.
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.
If you're wrapping the response from fetch for an error, I would suggest using throw Object.assign(new Error("Fetch Error"), { response }); This gives you the full context instead of response.toString() as the error message. Something I do in practice for my API endpoints is always return {result} or {error} from my API. An object where a root error can be checked against, or the result... This way I can have a very consistent handler, which is usually a wrapper around fetch as I'm not currently supporting any non-green browsers and fetch has been around for long enough now.