If you are dealing with a security focused implementation, there's also sessionStorage which has pretty much the same interface, but limited to a single tab/window. I use this for development in syncing/storing redux state, so that it can refresh the screen and keep the same redux state.
It also helps if you need to be able to impersonate other users in another tab, etc. You can pass an initial key/token when opening a new windows.
Niggle: this output is *NOT* JSON. JSON is a string, it's always a string that represents a primitive value, array or object structure in JavaScript notation.
What you have is an RSS parser for JavaScript.
Double negation coerces any value in JS to a Boolean of true or false.
It is important to know that there are seven values that evaluate as false in an evaluation context, these "falsy" values are as follows:
1. false
2. 0
3. -0
4. NaN
5. null
6. undefined
7. "" // empty string
Every other value is truthy.
Knowing this can clean up and cut down a lot of code. Personally it irks me to no end when I see something like...
if (v === null || v === undefined ...) return null;
Which can be more easily evaluated as `(!v)` first... sometimes you'll want to allow 0 `(!v && v !== 0)`
I understand that it's your project and that you are passionate about it. If you'd please limit your neo.mjs posts to maybe a one or two a week. Unless there's a significant release or change set, it's going to do more damage to your efforts than help. At this point, it's really on the edge of spammy given the posting frequency.
Maybe do a series of articles actually creating something with the framework.
I'm hoping that this leads to more stability with NPM, and maybe a bit of distancing from the politics of the organization. I really appreciate the work GitHub has done lately in expanding its' offerings. I think that it's a really good fit, and will be interesting to see what happens in terms of likely merging NPM's commercial offerings with the GitHub services.
This is currently, without a LICENSE file in the root of the project, or for that matter in the package.json file, meaning it is under copyright and not permitted for use by anyone other than the author.
The bundle size for Antd is twice what I allow for the uncompressed size of most of my entire apps including styles and core images/icons with @material-ui. Just, don't do it.
For react components, be sure to have a peer-dependency with an appropriate range setup for your features used.
For example:
"peerDependencies": {
"react": ">=16.11.0 <18.0.0"
Start with the version of react you're testing against and up to the version after next. React does very well at not removing features until a version after next... in the example above, 16.11.0 has the feature needed, and your component is up to date, and not using anything marked deprecated. This way you can generally rely on the features in use until the version after next (18).
----
On a typescript definition file, this also is beneficial to all users of VS Code, or where code completion is based on or enhanced by typescript definitions, including JS usage in VS Code.
----
On publishing, if you're on a public repository, and you should probably be for public packages, you should use a CI/CD pipeline based on a trigger, tag or admin comment for a release on PR approval. It's relatively easy to automate.
If you're creating a fork of an existing project, prefer namespacing for your package naming... it will help to avoid confusing names like foo3, etc where @yourid/foo would be better.
Double negation coerces any value in JS to a Boolean of true or false. It is important to know that there are seven values that evaluate as false in an evaluation context, these "falsy" values are as follows: 1. false 2. 0 3. -0 4. NaN 5. null 6. undefined 7. "" // empty string Every other value is truthy. Knowing this can clean up and cut down a lot of code. Personally it irks me to no end when I see something like... if (v === null || v === undefined ...) return null; Which can be more easily evaluated as `(!v)` first... sometimes you'll want to allow 0 `(!v && v !== 0)`For react components, be sure to have a peer-dependency with an appropriate range setup for your features used. For example: "peerDependencies": { "react": ">=16.11.0 <18.0.0" Start with the version of react you're testing against and up to the version after next. React does very well at not removing features until a version after next... in the example above, 16.11.0 has the feature needed, and your component is up to date, and not using anything marked deprecated. This way you can generally rely on the features in use until the version after next (18). ---- On a typescript definition file, this also is beneficial to all users of VS Code, or where code completion is based on or enhanced by typescript definitions, including JS usage in VS Code. ---- On publishing, if you're on a public repository, and you should probably be for public packages, you should use a CI/CD pipeline based on a trigger, tag or admin comment for a release on PR approval. It's relatively easy to automate. If you're creating a fork of an existing project, prefer namespacing for your package naming... it will help to avoid confusing names like foo3, etc where @yourid/foo would be better.