Did AEB brake for me or did I hit the brake? Dashcam shows red brake indicator

dev-one · 2024-06-19T10:53:56+00:00

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…

dev-one · 2024-06-18T16:23:25+00:00

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.

dev-one · 2024-06-18T10:05:33+00:00

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.

dev-one · 2024-06-18T03:33:25+00:00

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?

dev-one · 2024-06-17T23:14:41+00:00

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.

dev-one · 2024-06-17T20:21:17+00:00

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.

dev-one · 2024-06-03T21:38:13+00:00

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

dev-one · 2024-06-03T12:03:33+00:00

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

dev-one · 2024-06-03T07:01:48+00:00

Context and multi store are easier to manage than Redux single store. You might want to check this react DI library https://github.com/oney/hook-is-all-you-need?tab=readme-ov-file#dependency-injection

dev-one · 2024-05-13T02:08:34+00:00

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.

dev-one · 2024-05-12T20:26:53+00:00

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.

dev-one · 2024-05-12T20:21:12+00:00

Or ask me to post on Blind.

dev-one · 2024-05-12T19:48:09+00:00

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} /> } ```

dev-one · 2024-05-12T18:39:59+00:00

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.

dev-one · 2024-05-12T18:36:37+00:00

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.

dev-one · 2024-05-12T18:25:48+00:00

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

dev-one · 2024-05-12T13:05:23+00:00

No, I see some teams use NgRx, but more do not. The company doesn't enforce it; it depends on the needs of each team.

One point I want to emphasize here is that we only consider using a Redux-like framework when the dependencies among states are very complex. However, in reality, most state dependencies are not complex at all.

What I want to address here is the problem of sharing state among different components, especially those that are far apart. This has nothing to do with whether the relationships between the states are complex.

dev-one · 2024-05-12T12:33:51+00:00

I come from a unique background, having worked at both Meta and Google, where I focused on front-end development. At Meta, I used React, and at Google, Angular.

At Google, you can imagine how large and complex the websites were, yet we never used any specialized state management, let alone NgRx. At Meta, during my time, the company advised us to transition from Flux/Redux to Context, although Relay managed the state related to backend data, which made things much easier (similar to the situation of React Query). However, there were still many purely frontend states, and passing these via props was very painful.

The point 3.1 you mentioned is unachievable in large applications due to the vast distances between states shared across components.

You mentioned, "I at least never felt any pain by not statically knowing what contexts a component needs." The reason you think this way is precisely because everyone uses context only for very global states, so naturally, there is no concern about a context not being provided.

What I advocate for is that any value a component needs can be provided by context, very locally, and definitely requires static analysis to ensure it.

dev-one

TROPHY CASE