proposal-nullish-coalescing
proposal-optional-chaining
| proposal-nullish-coalescing | proposal-optional-chaining | |
|---|---|---|
| 5 | 5 | |
| 1,232 | 4,985 | |
| - | - | |
| 0.0 | 1.1 | |
| over 1 year ago | over 2 years ago | |
| HTML | HTML | |
| - | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
proposal-nullish-coalescing
-
Unveiling Breakthroughs Found In The State Of JS 2022 Survey
For more info about this feature, you can refer to the original proposal.
-
Javascript: El operador nullish-coalescing
Propuesta
-
PEP 505 – None-aware operators (2015)
For comparison, here are the Javascript RFCs for the equivalent operators:
https://github.com/TC39/proposal-optional-chaining
https://github.com/tc39/proposal-nullish-coalescing
IMO optional chaining is a lifesaver when dealing with deeply nested JSON, and it's become indispensable in our Typescript code. But we also deal with JSON from various third-party endpoints in Python, and far too often we resort to an inefficient deep_get utility to make our code sensical.
> if json?.get("foo")?.get("bar")?[0]?.get("baz")
may seem messy but would be infinitely better than the fragile (note the nested list-of-a-single-dict, and how bugs can appear if it's not there):
> if json.get("foo", {}).get("bar", [{}])[0].get("baz")
or the inefficient
> if deep_get(json, "foo.bar.0.baz")
It's not nearly as good as the Typescript json.foo?.bar?.[0]?.baz - but it's good enough!
- Stage 4: Nullish Coalescing for JavaScript
-
Using the optional chaining operator in JavaScript
The nullish coalescing proposal provides a way to handle undefined or null values and provide default values for the expression. You can use the “??” operator to provide a default value for an expression.
proposal-optional-chaining
-
What Operators Do You WISH Programming Languages Had? [Discussion]
Nullable property access can be useful sometimes
-
PEP 505 – None-aware operators (2015)
For comparison, here are the Javascript RFCs for the equivalent operators:
https://github.com/TC39/proposal-optional-chaining
https://github.com/tc39/proposal-nullish-coalescing
IMO optional chaining is a lifesaver when dealing with deeply nested JSON, and it's become indispensable in our Typescript code. But we also deal with JSON from various third-party endpoints in Python, and far too often we resort to an inefficient deep_get utility to make our code sensical.
> if json?.get("foo")?.get("bar")?[0]?.get("baz")
may seem messy but would be infinitely better than the fragile (note the nested list-of-a-single-dict, and how bugs can appear if it's not there):
> if json.get("foo", {}).get("bar", [{}])[0].get("baz")
or the inefficient
> if deep_get(json, "foo.bar.0.baz")
It's not nearly as good as the Typescript json.foo?.bar?.[0]?.baz - but it's good enough!
-
Optional Chaining `?.` do multiple null checks
Current Status: ECMAScript proposal at stage 4 of the process.
-
PHP 8 features I wish also existed in JavaScript
In JavaScript you still have to check step by step, if the corresponding property exists. There is a corresponding TC39 proposal which is in stage 4 by now and I'm really looking forward to this being part of the ECMAScript Specs.
-
[AskJS] Over-using optional chaining. Is this pattern common?
https://github.com/tc39/proposal-optional-chaining#is-this-error-suppression
What are some alternatives?
proposal-top-level-await - top-level `await` proposal for ECMAScript (stage 4)
hoogle - Haskell API search engine
proposal-regexp-match-indices - ECMAScript RegExp Match Indices
roast - 🦋 Raku test suite
proposals - Tracking ECMAScript Proposals
Forscape - Scientific computing language
babel-sublime - Syntax definitions for ES6 JavaScript with React JSX extensions.