Probably a bit more than 10 minutes... nice getting started walk through with Angular.
Aside: most of the advertorials from 2mc get deleted, it's nice to see actual content worth keeping on this feed.
While I agree with the sentiment... I'd add a couple things.
First, you should have a global error trap (for client side apps/spas) that blows up the world, logs to the console and replaces the entire body content with a generic error. This ensures you are properly capturing errors. This should include the same error trap inside your main react component. By doping this, you can then prioritize trapping expected error conditions to avoid the fallback, while always having a fallback. Too many applications blindly swallow, or worse don't handle uncaught errors (promises, react render, global error handler). If this is a Node application, also stop the world, log, wait a full minute then restart.
Second: always have a *UNIQUE* code for each location in code where you may raise an error condition for your own errors. This allows you to track down where it was raised quickly... If you are bubbling up...
catch(error) {
// catch and ensure a unique code is attached for
// finding where errors are coming from.
throw Object.assign(error, {code: error.code || 'UNIQUEID' });
}
Yes, you should absolutely display better error messages to the user... however, too many application projects I've come into don't even get the basics down right first.
I would recommend updating the article to use the *CURRENT* version of go, not a year and a half old release. The only reason I am not removing the article (off topic for JS site) is that it *could* be useful to someone that wants to use Go for webassembly development.
Go and Rust in particular seem to be two of the better options for wasm. C# is gaining some ground. C/C++ are also options, but often require more tweaking and knowledge to get started with.
I was probably overly critical, but even the libraries I looked at that did break them up were pretty big... I understand that it may be useful or worth it when you do need more complex, or larger visuals without the time to work through the math/render yourself. With a JSX supported interface, you can actually do a lot of SVG work with far less additional overhead in the browser, right now that's generally my goto for the few areas of the apps I'm working on requiring more complex/interactive visuals.
I'm not a total minimalist here. I strive to keep my payload (min+gz) as small as reasonable, generally under 300-500k, though I love when I can deliver under 100k. This often turns into 1-2mb parsed, and a 3-5mb logic tree in memory. Some of the charting libraries in the article take that much by themselves. This may not seem like much, but it's often quite a bit of overhead on a modest laptop. 300kb is actually enough room to bring in a *LOT* I'm using several react/redux libraries and a couple dozen Material-UI components as well as quite a few SVG icons (mdi-material-ui) and a lot of custom components for the project (about 20-25% of total payload)
There is absolutely no mention of or consideration of size delivered, parsed or computed in the article. Your referenced AnyChart, the core is over 300kb delivered by itself... the pie chart on top of that isn't bad at around 18kb, though there are other pie chart libraries that are stand alone in the 4-5kb range. Both min+gz. I could probably run core + pie through closure compiler to see how small it can be though. Right now, my main projects are an SPA where the entire payload is at 380k min+gz, and another where it's around 130kb. AnyChart's core would just about double my larger app. And is 2.5x the size of the smaller.
In the end, you and anyone else can make their own decisions on how/what to bring into their projects. That said, all of the charting libraries mentioned (I only looked at a few of them, admittedly) are considerably larger than I would consider for *MOST* applications. I know a lot of people are fine sending many megabytes of various modules/libraries down to the browser and either don't know or care about the impact/overhead. I know a lot of others that go to the opposite extreme, working hard to keep delivery under 30-50k max. I'm a bit more pragmatic, and even then these charting libraries are over the top for me.
material-components vs material-ui ... The name of the design style is "Material Design". material-ui is a React component library that implements Material Design. material-components is a Web Component library that implements Material Design. material-ui for React is the most popular material design library.
The only thing I really hate about all of them, is they are huge monolithic libraries and upwards of a meg of JS because you can't pluck out just enough for say a pie chart with overlays.
Given the audience, a link to the github repo would be more appropriate (GPL3 license) [1]. It's an interesting idea.
Also worth noting the backend does seem to be Java based.
[1] https://github.com/bastillion-io/Bastillion
The only implementations of JWT I've actually seen in the wild, or would actually support are using asynchronous RSA public/private key signing. This allows you to have a trusted signing authority, which is imho better than a shared secret between two systems.
Also, only use trusted authorities where the actual public key is side-loaded from an internalized resource. Do *NOT* trust/use the header portion of JWT for this part.
The article itself is a bit too shallow and doesn't really discuss how this can work in access infrastructure, which becomes more common in a corporate or larger social interaction. There's also how to develop/design services to consider.
Beyond this are considerations for token duration, refresh and revocation.
NOTE: currently working on an access/identity management system centered around JWT tokens for multiple applications.
While I agree with the sentiment... I'd add a couple things. First, you should have a global error trap (for client side apps/spas) that blows up the world, logs to the console and replaces the entire body content with a generic error. This ensures you are properly capturing errors. This should include the same error trap inside your main react component. By doping this, you can then prioritize trapping expected error conditions to avoid the fallback, while always having a fallback. Too many applications blindly swallow, or worse don't handle uncaught errors (promises, react render, global error handler). If this is a Node application, also stop the world, log, wait a full minute then restart. Second: always have a *UNIQUE* code for each location in code where you may raise an error condition for your own errors. This allows you to track down where it was raised quickly... If you are bubbling up... catch(error) { // catch and ensure a unique code is attached for // finding where errors are coming from. throw Object.assign(error, {code: error.code || 'UNIQUEID' }); } Yes, you should absolutely display better error messages to the user... however, too many application projects I've come into don't even get the basics down right first.