I'd really like to see articles like this using fetch api[1] directly over axios. It's not that Axios doesn't work, but it's over 12kb (4.3kb min+gz)[2] .. you could do every call long form with fetch for less, you can do better still with a custom simple wrapper around it.
[1] https://caniuse.com/#feat=fetch
[2] https://bundlephobia.com/result?p=axios@0.19.0
These are pretty much the only features I'm still using Babel for… pretty much everything else is already in modern browsers and the current/latest Node.
Seems like the optional chaining operator has sat in limbo forever, recently moved to stage 3 iirc.
Another one is the pipeline operator. I'm hoping the F# syntax wins in the end.
One thing to consider as a second pass, would be to wrap this in a pool or queue that returns promises. capture the worker, a resolve/reject and the on handlers use the captured handlers or throw.
This way you can do expensive processors as a limited pool of workers. I've done similar to this with separate child_processes before.
One piece not covered is bitwise shift, which is useful for setting flags in a clear way, for example.
const LIST_FRACTION = 1 << 0; // (001)
const LIST_UNIQUE = 1 << 1; // (010)
const LIST_SORTED = 1 << 2; // (100)
Beyond that, you don't need to check against the flag, since a match will be non-zero (truthy)
if (flag & LIST_UNIQUE) {}
I use Lighthouse built into chrome, but also use the WAVE and AXE extensions as well... they each have advantages/disadvantages over each other, with maybe 80% overlap.
Things you should put in your claims...
* token id
* real name
* account id
* email address
* user's roles/groups
example, here's a claims section from a devauth application I wrote.
{
jti: "GENERATED_UUID_FOR_THIS_TOKEN"
iss: "https://AUTHENTICATION_SERVER/"
aud: "https://APP_SERVER/",
iat: 1564526297, // Issued, seconds since unix epoch UTC
exp: 1564569497 // Expires, seconds from unix epoch UTC
sub: "USER_ID",
eml: "EMAIL_ADDRESS",
fnm: "FIRST",
lnm: "LAST",
aff: ["AFFILIATION",...]
rol: ["ADMIN",...]
}
OMFG!!! Do *NOT* put passwords or any secrets in your claims... the JWT itself is *NOT* encrypted/secure, the payload is only base64 encoded, the signature only confirms authority.
JSON.parse(atob(YOUR_TOKEN.split('.')[1]))
This is a *REALLY* bad example.
One piece not covered is bitwise shift, which is useful for setting flags in a clear way, for example. const LIST_FRACTION = 1 << 0; // (001) const LIST_UNIQUE = 1 << 1; // (010) const LIST_SORTED = 1 << 2; // (100) Beyond that, you don't need to check against the flag, since a match will be non-zero (truthy) if (flag & LIST_UNIQUE) {}Things you should put in your claims... * token id * real name * account id * email address * user's roles/groups example, here's a claims section from a devauth application I wrote. { jti: "GENERATED_UUID_FOR_THIS_TOKEN" iss: "https://AUTHENTICATION_SERVER/" aud: "https://APP_SERVER/", iat: 1564526297, // Issued, seconds since unix epoch UTC exp: 1564569497 // Expires, seconds from unix epoch UTC sub: "USER_ID", eml: "EMAIL_ADDRESS", fnm: "FIRST", lnm: "LAST", aff: ["AFFILIATION",...] rol: ["ADMIN",...] }OMFG!!! Do *NOT* put passwords or any secrets in your claims... the JWT itself is *NOT* encrypted/secure, the payload is only base64 encoded, the signature only confirms authority. JSON.parse(atob(YOUR_TOKEN.split('.')[1])) This is a *REALLY* bad example.