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

Lessons from migrating a large codebase to React 16

blog.discordapp.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Lessons from migrating a large codebase to React 16

#31

Post by tedeh »

buf wrote: post #17
realusername wrote: post #11

In my case, the main pain points were third-party packages, more than React 16 itself. For react you only had prop-types and createClass to change everywhere. The migration of react-router in particular was awful, the new react-router is so different from the old one they should have created another repository for the new version.

Completely agree. The new react router is a massive step back in the same code base. Rewriting apps in the new version is a massive pain.

That is true, but the new react-router makes better use of the component hierarchy which is the real beauty of React IMHO, by having the route components render conditionally based on the url.

We had a lot of pain doing this rewrite ourselves, but I must say it was worth it in the end.

Unfortunately, this is major version 4, so who is to say that the repo maintainers don't find an even better way to do it in six months, prompting a version 5 and so on...

Re: Lessons from migrating a large codebase to React 16

#32

Post by linkmotif »

pluma wrote: post #22
chairmanwow wrote: post #6

This seems like engineering for engineering's sake. From the author's description, this was a pretty superficial refactoring that may or may not have been for the better. It seems like a bizarre decision to spend time migrating to a new system / tool that provides no immediate benefits. A thorough refactoring of their codebase seems like it would have been a better use of engineering time.

I've migrated two applications from React 15 to 16 and it was completely painless. I only had to bump all dependencies to the latest version. Literally the only reason a migration could be painful if you're on the latest version of 15 before upgrading is that your code or your dependencies are using deprecated APIs, which the latest version of React 15 will helpfully warn about. You can fix that before migrating.

You probably weren’t mutating props...

My eyes kinda got wide when I read that part.

Re: Lessons from migrating a large codebase to React 16

#33

Post by conatus »

chairmanwow wrote: post #6

This seems like engineering for engineering's sake. From the author's description, this was a pretty superficial refactoring that may or may not have been for the better. It seems like a bizarre decision to spend time migrating to a new system / tool that provides no immediate benefits. A thorough refactoring of their codebase seems like it would have been a better use of engineering time.

I'm afraid with all due respect to the author, I have to concur.

"Right now, it isn’t clear that the advantages are significant" - so why invest the time in doing so? Why not use a tried and tested version until such times as you either need features from the newer version or some third party dependencies you absolutely need require it?

Re: Lessons from migrating a large codebase to React 16

#34

Post by bryanlarsen »

heavenlyblue wrote: post #26
gingerb wrote: post #25

This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle". I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React…

It's impressive how most of the progress in the JS land is essentially adding the features most of the other languages have already had for years (or - at least had done them properly in the first place). And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.

Sure, Haskell & OCaml have had a lot of these features for years, but they can hardly be called "most languages". Other languages are also in the progress of adding similar features (C++, for example) or aren't getting them (C).

Javascript has more library churn, but the alternative is being stuck on something like BOOST. ugh.

Re: Lessons from migrating a large codebase to React 16

#35

Post by Sacho »

gingerb wrote: post #25

This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle". I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React…

> I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?

Who's forcing you to do this? All of these old things still work. If your team/job are forcing you to do this, then why is the problem not with them, rather than the language/ecosystem?

Re: Lessons from migrating a large codebase to React 16

#36

Post by bromuro »

weego wrote: post #28
heavenlyblue wrote: post #26

Earlier quoted context omitted.

It's impressive how most of the progress in the JS land is essentially adding the features most of the other languages have already had for years (or - at least had done them properly in the first place). And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.

It's also incredibly frustrating that every step that is rediscovered that other languages just have is then subject to endless fragmentation over trivial differences that are put forward as core philosophical concerns. I know this is not unique to the JS ecosystem but it's definitely a lot worse than I've seen in the past.

Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms.

Those times were painful, now it’s much much better.

Re: Lessons from migrating a large codebase to React 16

#37

Post by mercer »

davedx wrote: post #27
realusername wrote: post #11

In my case, the main pain points were third-party packages, more than React 16 itself. For react you only had prop-types and createClass to change everywhere. The migration of react-router in particular was awful, the new react-router is so different from the old one they should have created another repository for the new version.

This has been my experience of react-router since its inception. When react-router does a major API version bump, they really mean it. I don't use it in any projects I have full control over, but unfortunately due to its popularity in larger projects I've had to use it.

Agreed! After being burned by React-Router, more than once, I actually would opt for manually implementing a Redux-et-all solution with something like History.js over using React-Router again. Which is pretty worrying considering how important routing is, or should be, in the ecosystem.

Re: Lessons from migrating a large codebase to React 16

#38

Post by christophilus »

hex13 wrote: post #30

"Facebook has done a good job of deprecating and warning for the last few months, but not all libraries are well-maintained and if you depend on or have forked a great many ancient ones, you will be in for a bit of a slog."). This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React base…

Agree 100%. I always use zero-dependency libraries if they are available. The only library in my codebase that has a React dependency is react-redux. React upgrades have thus far been painless.

Re: Lessons from migrating a large codebase to React 16

#39

Post by Touche »

Sacho wrote: post #35
gingerb wrote: post #25

This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle". I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React…

> I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea? Who's forcing you to do this? All of these old things s…

> All of these old things still work.

The old things likely have bugs. And most libraries don't spend a lot of time patching old versions (why should they, it's free software). The longer time passes the less and less likely there will be bug/security patches. So if you want to own those bugs/security issues, sure, stay behind to avoid the cost of upgrading.

Re: Lessons from migrating a large codebase to React 16

#40

Post by Touche »

This is why I prefer web components. This is nothing against React. But it's a library, and they make breaking changes just like all libraries (eventually) do.

The great thing about web components is that they cannot make breaking changes now that it's been implemented by multiple libraries. It's stamped in time forever.

If there ever comes a time where the existing API can't be updated any more because of mistakes or whatever, they'll just make a new API and your existing code will continue to work, forever. Look at XMLHttpRequest and fetch(). Did you have to migrating your XHR code over to fetch()? No, it works fine, and always will.

Post reply on HN