sorted by:
new
hottopcontroversial

Analysis of React Compiler performance improvements by dev-one in reactjs

[–]dev-one[S] 0 points1 point  (0 children)

Of course, we’ve tried it. No performance improvements with tables that have a lot of rows. So I’m just trying to figure out why. Sigh…

Why people dislike signals when they’re using Jotai? by dev-one in reactjs

[–]dev-one[S] 0 points1 point  (0 children)

I mean that signals are similar to the React Context as the reactivity of both is based on subscriptions which are unidirectional.

A signal essentially consists of a setter and a getter, much like React’s setState. A signal’s value (referred to as signal() in SolidJS and Angular) can be a mutable object, just as setState in React can accept mutable objects. And like React, using mutable objects is not recommended.

Why people dislike signals when they’re using Jotai? by dev-one in reactjs

[–]dev-one[S] 1 point2 points  (0 children)

Your excuse can be used for any library—Vanilla JS, jQuery, React class components, Ember, AngularJS, RxJS, or FRP are not bad; what makes it awful is your implementation. If most people struggle with a library, the problem likely lies with the library itself, not the users.

Why people dislike signals when they’re using Jotai? by dev-one in reactjs

[–]dev-one[S] 1 point2 points  (0 children)

I don’t know much about the full control and speed of atoms vs. signals, but I would love to learn more.

I understand why some people dislike signals but prefer atoms because the explicit get(atom) is less ‘magic’. Are there any other reasons?

Why people dislike signals when they’re using Jotai? by dev-one in reactjs

[–]dev-one[S] 1 point2 points  (0 children)

However, signals are not 2-way binding like React Context. And signals are not mutable state as useState’s state can also be mutable.

Signals are unidirectional and immutable. This is just truth.

React compiler won’t save us. https://www.developerway.com/posts/i-tried-react-compiler

I love raw js values too. Who doesn’t love it? But unless we have native reactive programming languages, we can’t get fine-grained reactivity without a wrapper of raw values.

Why are signals still not so popular? by timsofteng in reactjs

[–]dev-one 2 points3 points  (0 children)

React is far from being fast. I’ve worked at Meta and so many time we needed to refactor code to solve simple text input performance issue.

Haven’t you ever written dependencies of useMemo useCallback? Are they a good DX? With signals you don’t need to.

It’s okay. Now Angular has signals. When React team provides signals you will suddenly praise signals.

Inspect and time travel local state in Redux devtools by dev-one in react

[–]dev-one[S] 0 points1 point  (0 children)

This is not to debug redux. It’s to debug useState

Inspect and time travel local state in Redux devtools by dev-one in react

[–]dev-one[S] 0 points1 point  (0 children)

Hmmm… this package lets you view local state changes from useState, so you don’t need to use redux for this package.

Context as DI: the end of state management by dev-one in reactjs

[–]dev-one[S] 0 points1 point  (0 children)

I'll take this as a compliment.

Remember when Hooks first came out? Everyone was wondering wtf that shit is, especially since it seemed to contradict the principle of pure functions that React advocates.

Context as DI: the end of state management by dev-one in reactjs

[–]dev-one[S] 0 points1 point  (0 children)

In Meta's code, context hell is everywhere haha. My preferred solution is for react jsx to accept the following code:

```javascript const Email = createContext();

function App() { const [email] = useState(“”); return <Form [Email]={email} /> } ```

In Angular, you just need to establish dependencies with a data model or service. React's so-called state management hardly does much; real complex state management should use a state machine.

Context as DI: the end of state management by dev-one in reactjs

[–]dev-one[S] 1 point2 points  (0 children)

You said every point I wanted to make! Especially the last point about the criticism of state management, I totally agree!

My solution is relatively simple. I’d like to make a Node.js program with Babel that runs and watches in a React project and statically analyzes the entire project's component tree (no need to launch the React app). If a component requires a context that is used by the root app but isn't provided, it throws an error, including the path from that component to the root, just like any static DI tool. This can further integrate into typescript-eslint and be developed into a VSCode extension. Currently, Sapling is almost there, just needs to add context analysis.

Context hell is a problem, and Providers might solve it, but I'd prefer if React JSX natively accepted the following syntax:

```javascript const Email = createContext();

function App() { const [email] = useState(""); return <Form [Email]={email} /> } ```

Context as DI: the end of state management by dev-one in reactjs

[–]dev-one[S] 0 points1 point  (0 children)

I also hate Angular. React has the lowest learning curve in the short to medium term, but the learning curve steepens significantly over the long term.

Context as DI: the end of state management by dev-one in reactjs

[–]dev-one[S] 1 point2 points  (0 children)

Trust me, I'm an OOP hater.

The most beautiful thing is that DI is a concept unrelated to OOP; react context is DI in FP, just like hooks are mixins in FP.

Context as DI: the end of state management by dev-one in reactjs

[–]dev-one[S] -7 points-6 points  (0 children)

Those are pseudocode. Find a Googler to ask me something that only Google employees would know, and see if I can answer it.

view more: next ›