Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I wish I knew about React

bitsofco.de

Post reply on HN
Print view View original

121–130 of 301 posts

Re: What I wish I knew about React

#121

Post by osdiab »

baddox wrote: post #113
osdiab wrote: post #30

Earlier quoted context omitted.

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my…

The SSR data fetching story really isn’t much different than the story for managing global state in React on the client. It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”). But…

There’s other problems too - all components need to be runnable serverside (which adds complexity to otherwise simple operations on the dom), forcing yourself to put all state into a redux store even if you’re not planning to share it is more unnecessary boilerplate/overhead - and there isn’t any clear canonical way to achieve this for arbitrary apps.

I’m finding it tricky to implement cleanly in my company’s fairly large React codebase, though I do think the fundamental problem is not a simple one and requires tradeoffs.

Re: What I wish I knew about React

#122

Post by villuv »

ivan_gammel wrote: post #94
osdiab wrote: post #65

Earlier quoted context omitted.

What do you think HTML is for? If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React. If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer. Re s…

Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on build…

Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 95. What happened, guys?

Re: What I wish I knew about React

#123

Post by yazaddaruvala »

genezeta wrote: post #73
capableweb wrote: post #58

Earlier quoted context omitted.

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as bo…

Yes. That's the other way of expressing the distinction between frameworks and libraries. And I think most people do use React as a framework. (But I could be underestimating those who use it in the second way, of course).

I can give a production example of migrating to React.

We needed to do it incrementally from a server side rendered Java application, with jQuery and a lot of custom spaghetti code.

At first we migrated the server side templates to JSX and started to use React as a library by calling ReactDOM.renderToString. The first thing our JavaScript did was render the React templates similar to using Handlebars. Then the rest of our code kicked in using jQuery bindings and it’s events logic.

Now that our templates were all JSX. It was simple that start converting leaf “components” with simple state into ReactDOM.render instead. Often needing ReactDOM.unmountComponent to “refresh” the state And rerender everything like the jQuery based code needed.

Finally, we worked our way up the stack of components so that more and more were “just normal react components without calls to ReactDOM.

The last thing we did was migrate the top level to use ReactDOM.render and we were fully React based.

FWIW, we thought about Redux but didn’t use it. We used the patterns from Redux, but felt we didn’t need a library to manage our data. This was also pre-Hooks.

All in all took 1 dev on a team of 9, that all kept working on the codebase, about 4 months working on it off and on 50% time focused on the migration.

There were no issues caused along the way, the automated tests didn’t need to be changed (except for the new features - which were orthogonal to the React migration), and customers had a (unnoticeable) latency improvement comparing the metrics at the start and end of the migration.

The incremental use was a huge reason we picked React. Not only to migrate to React but also because we can do the inverse process when we want to migrate away.

P.S. We finished this migration Jan 2019. Since then the productivity of the team has noticeably increased. Even new hire “ramp up” has been reduced with them producing production code faster, on average, than pre-React. I’m sure these successes would be true for a migration to any modern UI tool e.g. Angular or Vue.

Re: What I wish I knew about React

#125

Post by Alterlife »

dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

Does this article qualify as 'hate' though? The author acknolwdges that he's new to react and is simply pointing out two things that he found challenging.

Nothing surprising. Infact, I don't understand why the article is so highly upvoted.

Re: What I wish I knew about React

#126

Post by jchw »

Alterlife wrote: post #125
dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

Does this article qualify as 'hate' though? The author acknolwdges that he's new to react and is simply pointing out two things that he found challenging. Nothing surprising. Infact, I don't understand why the article is so highly upvoted.

This was my first thought, but the parent comment is probably referring to the comments that were on top at the time it was written, rather than the article (which I agree, is fairly mundane, although I think it’s fine.)

Re: What I wish I knew about React

#127

Post by lindskogen »

batiste wrote: post #106
awestroke wrote: post #5

Earlier quoted context omitted.

No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.

Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?

Not in a single method, no. Watch this talk for more details! https://www.youtube.com/watch?v=wXLf18DsV-I

Re: What I wish I knew about React

#128

Post by arvinsim »

conmigo wrote: post #117
prodave wrote: post #2

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about h…

const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change.

const is not "constant".

In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.

Re: What I wish I knew about React

#129

Post by baddox »

osdiab wrote: post #121
baddox wrote: post #113

Earlier quoted context omitted.

The SSR data fetching story really isn’t much different than the story for managing global state in React on the client. It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”). But…

There’s other problems too - all components need to be runnable serverside (which adds complexity to otherwise simple operations on the dom), forcing yourself to put all state into a redux store even if you’re not planning to share it is more unnecessary boilerplate/overhead - and there isn’t any clear canonical way to achieve this for arbitrary apps. I’m finding it tricky to implement cleanly in my company’s fairly…

It’s true that there’s no official React guidance on doing this, and doing so would probably require official React choices for routing, global state management, etc. which the React team is clearly not interested in doing.

But there are popular frameworks like next.js that have pretty simple patterns (like getInitialProps) that can probably be adapted to any React codebase.

Re: What I wish I knew about React

#130

Post by kristiandupont »

conmigo wrote: post #117
prodave wrote: post #2

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about h…

Wow, posts like these provide real counterweight to my desire to write open source software.
Post reply on HN