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.
Don't use the pre-built CSS in practice... setup your SCSS processor, and reference the built-ins directly... copy the main scss, update the paths and comment out the pieces you aren't using... override your variables (colors, details, options) and build directly. This will help you if you're integrating other tooling. Devs tend to make the mistake of modifying the original css build to change colors etc, and it winds up breaking things. Worse is when designers do it, and release patch css files for components, with a lot of duplications and more bugs.
Use the source, it's there for you.
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.