proposal-pattern-matching
proposal-decorators
proposal-pattern-matching | proposal-decorators | |
---|---|---|
67 | 64 | |
5,344 | 2,649 | |
0.9% | 0.5% | |
9.0 | 4.2 | |
9 days ago | 2 months ago | |
HTML | ||
MIT License | - |
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-pattern-matching
-
Coming to grips with JS: a Rubyist's deep dive
Note, however, that there is a proposal to add pattern matching to JS.
-
Level up your Typescript game, functionally - Part 2
There's an ECMAScript proposal that is in the works to add this feature to the language! It's going to look something like this.
-
Building React Components Using Unions in TypeScript
More importantly, TypeScript typically commits to build things into itself when the proposal in JavaScript reaches Stage 3. The pattern matching proposal in JavaScript is Stage 1, but depends on many other proposals as well that may or may not need to be at Stage 3 as well for it to work. This particular proposal is interested on pattern matching on JavaScript Objects and other primitives, just like Python does with it’s native primitives. These are also dynamic types which helps in some areas, but makes it harder than others. Additionally, the JavaScript type annotations proposal needs to possibly account for this. So it’s going to be awhile. Like many years.
-
Explicit Software Design. Preliminary Conclusions
For true™ functional programming in JS, native pattern matching and partial function application are missing (at least for now: 1, 2). For proper OOP, it lacks real interfaces and compile-time dependency injection.
-
TypeScript Is Surprisingly OK for Compilers
The proposal for pattern matching syntax seems more akin to what they're looking for.
https://github.com/tc39/proposal-pattern-matching
-
[AskJS] C# in every Node.js job posting?
There's a proposal to add something like that to JavaScript but it's been stuck in limbo since 2017 although there are libraries like ts-pattern which implement it already.
-
[AskTS] What do you think will be the future of runtime type checking?
I'll admit, it is easy to assert that the TypeScript language should not be involved in the matters of packages but I also wonder if we're moving towards a point where interfaces will be as common as namespaces and whether or not it would be sensible for the language to incorporate such type assertions into the language formally, after all, it already compiles to various forms of JavaScript and there is a stage 1 proposal submitted to the TC39 committee to give JavaScript pattern matching. If adopted, wouldn't it make sense to allow TypeScript to compile a type into a type guard for the native JavaScript pattern matcher?
- Updates from the 96th TC39 meeting
-
Mostly adequate guide to FP (in JavaScript)
Both are active tc39 proposals :)
https://github.com/tc39/proposal-pipeline-operator - Stage 2
https://github.com/tc39/proposal-pattern-matching - Stage 1
Hopefully we get both in the next couple of years.
-
CoffeeScript for TypeScript
We often add promising TC39 proposals into Civet so people can experiment without waiting.
We've added https://github.com/tc39/proposal-pipeline-operator, a variant of https://github.com/tc39/proposal-pattern-matching, a variant of https://github.com/tc39/proposal-string-dedent and others.
Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anything TC39 leaves on the table (rest parameters in any position, etc.)
proposal-decorators
-
Making Web Component properties behave closer to the platform
Because many rules are common to many attributes (the coerceType operation is defined by WebIDL, or using similar rules, and the HTML specification defines a handful of microsyntaxes for the parseValue and stringifyValue operations), those could be packaged up in a helper library. And with decorators coming to ECMAScript (and already available in TypeScript), those could be greatly simplified:
-
The case for using decorators in your codebase
Decorators are currently not a part of the standard JavaScript language. They are still being discussed in tc39 and have reached proposal stage 3. This means the spec has more or less stabilized and we can use them but they would be transplied before being run in the browser. This would be done via babel or tsc for most users
-
JavaScript Naming Conventions are Important
JavaScript was created a long time ago, and at the time of its inception, the authors decided not to use affirmative prefixes for boolean names. Now, they do their best by continuing to follow their convention, even if it goes against the community's opinion. Even if the authors wanted to introduce new naming conventions in the specification, they could not do it, at least not coherently. Old code cannot be renamed because JavaScript must remain backward-compatible. And starting to write new code using new approaches is not a great idea either, as there would be two ways to do the same thing, which is also undesirable.
-
ECMAScript Decorators. The Ones That are Real
2016-07 – Stage 2. After the decorators proposal reached stage 2, its API began to undergo significant changes. Furthermore, at one point the proposal was referred to as "ESnext class features for JavaScript." During its development, there were numerous ideas about how decorators could be structured. To get a comprehensive view of the entire history of changes, I recommend reviewing the commits in the proposal's repository. Here is an example of what the decorators API used to look like:
-
Strawberry - Zero-Dependency, Build-Free JavaScript Framework
The example you've given isn't valid JavaScript, JS doesn't have decorators. (Although there is a stage 3 tc39 for it, afaik no browser has implemented it)
-
Updates from the 96th TC39 meeting
There was a decorators issue brought up in the meeting (issue 508) and decorators metadata, as noted in the article, is now at stage 3. So there's still active work being done on decorators. If I had to guess, I'd say they'd be a likely candidate for ES2024.
-
The Lightweight Alternative to GraphQL, Resolvers Instead of Endpoints
As per the proposal, decorators can be used with Classes and their elements such as fields, methods, and accessors. To leverage this feature, we need to ensure that our resolvers provider is an instance of a Class. Therefore, we will modify the code in src/api/users/users-resolvers.js to the following:
-
Using modern decorators in TypeScript
The modern version of decorators, which will be officially rolled out in TypeScript 5.0, no longer requires a compiler flag and follows the official ECMAScript Stage-3 proposal. Alongside a stable implementation that follows ECMAScript standards, decorators now work seamlessly with the TypeScript type system, enabling more enhanced functionality than the original version.
-
What should I do after react js
100% this. Going in depth of libraries will make you so much better developer than learning newest and coolest frameworks in JS ecosystem. Learn to create your own React, Promises, or anything you like in JS. It will give you immense perspective about these libraries. Once you start understanding them you will feel like they are not that complex and you can do it too. Go read TC39 proposals and issues people point out in them. You will see how JS is borrowing features from other languages.
-
Announcing TypeScript 5.0
The actual proposal gives the "@reactive" decorator as the first example, which just so happens is the only decorator that I use in my library with TypeScript's legacy decorator option. Was so happy to see they recognize this use case! https://github.com/tc39/proposal-decorators
What are some alternatives?
fp-ts - Functional programming in TypeScript
openapi-typescript - Generate TypeScript types from OpenAPI 3 specs
package.elm-lang.org - website for browsing packages and exploring documentation
proposals - Tracking ECMAScript Proposals
content - The content behind MDN Web Docs
TypeORM - ORM for TypeScript and JavaScript. Supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, Oracle, SAP Hana, WebSQL databases. Works in NodeJS, Browser, Ionic, Cordova and Electron platforms.
ecma262 - Status, process, and documents for ECMA-262
remult - Full-stack CRUD, simplified, with SSOT TypeScript entities
proposal-pipeline-operator - A proposal for adding a useful pipe operator to JavaScript.
proposal-decorator-metadata
proposal-record-tuple - ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
arktype - TypeScript's 1:1 validator, optimized from editor to runtime