infernu
Immer
Our great sponsors
infernu | Immer | |
---|---|---|
2 | 141 | |
337 | 26,803 | |
- | 1.0% | |
0.0 | 7.2 | |
over 5 years ago | 2 days ago | |
Haskell | JavaScript | |
GNU General Public License v2.0 only | 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.
infernu
-
The TypeScript Experience
Or maybe a sound type system can only be achieved either by limiting JavaScript or with a different language that compiles to JavaScript?
-
Features of a dream programming language: 2nd draft.
Very constrained. Since "constraints liberate, liberties constrain", as Bjarnason said. Inspired by Golang's minimalism, and Elm's guardrails. For learnability and maintainability. Since discipline doesn't scale (obligatory xkcd: with too much power, and the wrong nudges, all it takes is a moment of laziness/crunch-time to corrupt a strong foundation), and a complex language affords nerd-sniping kinds of puzzles, and bikeshedding and idiomatic analysis-paralysis. Counter-inspired by Haskell. The virtue of functional programming is that it subtracts features that are too-powerful/footguns (compared to OOP), namely: mutation & side-effects. The language designers should take care of and standardize all the idiomacy (natural modes of expression in the language). "Inside every big ugly language there is a small beautiful language trying to come out." -- sinelaw. The language should assume the developer is an unexperienced, lazy, (immediately) forgetful, and habitual creature. As long as software development is done by mere humans. This assumption sets the bar (the worst case), and is a good principle for DX, as well as UX. The constrained nature of the language should allow for quick learning and proficiency. Complexity should lie in the system and domain, not the language. When the language restricts what can be done, it's easier to understand what was done (a smaller space of possibilities reduces ambiguity and increases predictability, which gives speed for everyone, at a small initial learning cost). The language should avoid Pit of Despair programming, and leave the programmer in the Pit of Success: where its rules encourage you to write correct code in the first place. Inspired by Eric Lippert, but also by Rust.
Immer
-
Immer VS mutative - a user suggested alternative
2 projects | 25 Jan 2024
-
Show HN: Cami.js β A No Build, Web Component Based Reactive Framework
```
It looks like itβs mutating, but both the reducers and update() uses immer* under the hood, so we still respect immutability under the hood.
Cami supports redux devtools so you can use that for time-travel debugging too!
β-
- Why do we need modules at all?
-
Making Sense of React Server Components
I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'?
-
The sword refers to immer, the faster and stronger immutable data js tool limu stable version released!
But is immer really the ultimate answer? The performance problem of immer is more prominent in large arrays and deep-level object scenarios. See this issue description, many authors in the community began to try to make breakthroughs, and noticed that structura and mutative, I found that it is indeed many times faster than immer as they said, but it still fails to solve the problem of both fast speed and good development experience. I will analyze the two issues in detail below.
-
Ramda: A practical functional library for JavaScript programmers
I like immer for this kind of thing: https://github.com/immerjs/immer
It gives you immutable updates without getting bogged down in FP abstractions.
-
Is there a better way to do read-only types
If you're trying to make things actually immutable, Object.freeze and deep copies can clutter things up pretty good, have you considered using something like immer? (https://immerjs.github.io/immer/)
-
5 React Libraries to Level Up your Projects in 2023
If you want to set up from Context, Zustand is your best bet. It offers an extremely simple API that lets you create a store with values and functions. Then, you can access that store from anywhere in your application to read and write values. Reactivity included! If you want to store nested object data in your store, consider using Immer alongside Zustand to easily change nested state.
-
What are some of the best libraries you cannot work without?
immer
-
How to synchronize access to application data in multithreaded asio?
I don't know about immer, do you mean the JavaScript library immer?
What are some alternatives?
immutability-helper - mutate a copy of data without changing the original source
immutable-js - Immutable persistent data collections for Javascript which increase efficiency and simplicity.
redux-toolkit - The official, opinionated, batteries-included toolset for efficient Redux development
Recoil - Recoil is an experimental state management library for React apps. It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.
react-query - π€ Powerful asynchronous state management, server-state utilities and data fetching for TS/JS, React, Solid, Svelte and Vue. [Moved to: https://github.com/TanStack/query]
zustand - π» Bear necessities for state management in React
valtio - π Valtio makes proxy-state simple for React and Vanilla
mori - ClojureScript's persistent data structures and supporting API from the comfort of vanilla JavaScript
redux-saga - An alternative side effect model for Redux apps
reselect - Selector library for Redux
JSON-Schema Faker - JSON-Schema + fake data generators
SWR - React Hooks for Data Fetching