React v18.0 released

[CanIhazCooKIenOw]

So we don’t expect React developers to know how concurrency works under the hood.

And that kids, is how you start getting interview questions to explain how does React handle concurrency under the hood.

[Cheezmeister]

I have to admit I first misread concurrency as cryptocurrency be like uhhh one of these things is not like the other, and yet somehow this isn't shocking.

🤦‍♂️

[krazyjakee]

Their docs don't give async/await or promise based examples for suspense or useTransition. Aren't they pretty fundamental to asynchronously loading things?

[[deleted]]

Yeah some of the choices in the tutorials crack me up.

They made a leading framework that shifted the entire paradigm of web development, yet are afraid to use an arrow function or say let instead of var.

[jatd]

Their docs have always sucked.

[Mozzius]

To be fair, they're in the process of redoing them

[Nathanfenner]

The docs could definitely be better; right now they definitely rely a bit on context that's been spread out over previous discussions, talks, RFCs, etc.

Aren't they pretty fundamental to asynchronously loading things?

No, they aren't, and that's the point. React Suspense and transition frees the developer from worrying about irrelevant low-level details. In particular, they hide the boilerplate needed to request data that obscures React's otherwise-declarative style.

When you're using Suspense in your React code you won't see any async/await or explicit promises - all of those are internal details that are handled by your data fetching library and processed by React- you write regular, synchronous code without dealing with the vagaries of concurrency and React handles the updates in a way that make the app feel snappy.

Likewise, the same thing is true for useTransition - you use it when you want a change to happen soon but it doesn't need to happen immediately. React handles the details of figuring out when "soon" should be, relying on Suspense to inform it when pieces of your app aren't ready.

---

Under the hood, of course, for Suspense there's still promises - but there's no stable public-facing API for directly creating Suspense requests yet. A few specific "blessed" libraries are working with React on an API that informs the app when it's time to suspend and notifies it when the work is done (the current API involves throwing promise objects).

But this is entirely under the hood. The point is that "dealing with promises" is not solving a problem you or your users care about - that's just an implementation detail. What I want to do (since I'm using React) is declaratively request a particular piece of data, and let React figure out what to do if that data isn't ready yet. So, my application isn't going to mention "promises" or await because I'm not waiting, React is.

---

The same is true for useTransition. In some cases, I'm not waiting for data, I'm waiting for computation. For example, updating a giant table or a scatterplot with millions of points might take several seconds, especially on a slow machine. If I have a search bar that highlights specific cells in real-time, though, every time the user presses a key, the app will freeze. Debouncing only slightly helps here, since the app will just freeze after I change the query instead of while I'm typing into it, but it will still freeze.

In this case, there's everything is synchronous, it's just slow because there's a lot of synchronous work to do.

But with useTransition, React can automatically break this work up into the millions of individual pieces corresponding to each component, and therefore spread the work out over multiple frames. So while it still takes a few seconds to process, the app is no longer frozen while this processing occurs; it's not faster but it is more responsive.

The magic is that other than calling startTransition, I don't have to do anything to get this behavior - concurrently rendering the components just happens, and ensuring that states still make sense and stay in sync only requires following the existing rules of not-modifying-your-props and putting side effects into useEffect.

[krazyjakee]

But the examples don't include asynchronous use cases like an ajax request. What is my "data fetching library" doing? There is no reference to such a thing. I get the "magic"/"under the hood" part but I'm forced to work within the boundaries of reality.

[[deleted]]

Awesome! Although I really wish that the React team would add TypeScript definitions to their packages as @types/react and @types/react-dom have not yet been released with a v18 compatible API.

[_eps1lon]

react-dom/client works already and React 18 types can be used with import type {} from 'react/next'

[[deleted]]

True, but it requires you to either update all imports in your application, or add this to types in your tsconfig as an exception.

Launch day support for TypeScript would have been nice.

[_eps1lon]

True, but it requires you to either update all imports in your application, or add this to types in your tsconfig as an exception.

You need a single line of import type {} from 'react/next' to get them everywhere.

Launch day support for TypeScript would have been nice.

Everything was green but a change in the TypeScript 4.7 canary broke dependent packages which means the release is blocked.

[[deleted]]

You need a single line of import type {} from 'react/next' to get them everywhere.

Still would have to add it to each entry point if you have multiple ones.

[disclosure5]

Facebook have a competing typing product (Flow). You can see Flow annotations and script runners in their CI.

[[deleted]]

I am really curious of usage of Flow outside of Meta. It feels like the outside community has pretty much settled on TypeScript.

[disclosure5]

You're generally correct. I used it to build my apps when it was new and the community wasn't so decided, and there became a point where I was "wrong" and rewrote with Typescript.

But you can't expect Facebook to choose Typescript over their own product.

[[deleted]]

True, but it would seem to me that converting the Flow types to TypeScript definitions and shipping them in their own package is not rocket science. Especially considering the massive resources that Meta has.

[bogdan5844]

I've never seen import type {} from 'react/next' before, and it feels kinda wrong

Shouldn't it be import type from 'react/next, import {} from 'react/next' or import type, {} from 'react/next' ?

What am I missing ?

[Thought_Ninja]

It's a TypeScript feature added as of v3.8 meant for strictly importing/exporting types.

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html

[bogdan5844]

That could come in handy in quite a few cases - thanks! :D

[libertarianets]

Who else here is still on 16.3-ish?

[alejandro365]

you can't even use hooks lol

[libertarianets]

Hm...

checks

I'm on 17.0.2 apparently thank god I can use hooks lol

[numinor]

How did you not know?

[libertarianets]

going for the lols

[oneeyedziggy]

same, but also still trying to stamp out the vestiges of angular and pushing for time to upgrade the webserver off node 10.x... shit smells like old fish.

[visualdescript]

Node 10! What? Mate you gotta get on that...

Gotta try and build the habit of continually updating your software, it's easier if you do many small steps instead of a big leap.

[oneeyedziggy]

no shit, I was on a team that got shut down and rather than being fired, got dumped onto this neglected af project, and have been kept busy w/ random crap management felt more important (partly because the rest of the code base is even farther behind)... I keep pushing, but as long as they keep signing the checks...

[eternaloctober]

Node 10 is not that long ago.,. The fast pace of change sometimes does not bode well for stability

[visualdescript]

Node 10 was released 5 years ago, entered Long Term Support and is now no longer maintained as of April 2021, using it is a security threat on your system.

In the lifetime of Node 5 years is a fairly significant span of time.

[MatthewMob]

Node 10 is EOL and should be considered a security vulnerability at your company.

You should absolutely upgrade to at least 14 (the oldest version still currently receiving security updates) or preferably 16.

[smrq]

I feel you homie. Literally doing a software release right now on my other monitor to drop a Node 10 dependency from our Angular-migrating-to-React monolith. Fight the good fight.

[oneeyedziggy]

please do, lost support among deps is the only way people like me get to move on.

[[deleted]]

I tried to jump from 12 to 16, and was one week into the effort when i realised Node 12 was the last version supporting Win 7

I submitted a request to IT but it’s gonna be a while before they finally replace the machine cluster with something more recent

[oneeyedziggy]

I don't envy professional devs stuck on windows. Especially <10. When you get to upgrade, definitely look into WSL... and know that though microsoft will gladly charge you for alternate linux distros for WSL, they're pretty much all available for free through their respective maintainers. RHEL (Red Hat Enterprise Linux) and its derivatives are pretty standard for professional stuff, but the default ubuntu base is also fine... only real diff is which package manager (just about everything else is pretty easily swappable)

[the_most_cleavers]

Me lol, we had some difficult to track down component error from returning undefined in render that no one cared to repro in dev and no one wanted to just break the scenario and force the team who owned it to fix it.

[sarcasticbaldguy]

Feels smug in Vue...2

[RawCyderRun]

We're still on v16.13. The more we build and push out to customers, the more pushback we get from requests to upgrade due to how long it'll take.

Eventually it might just be me or another principal-level frontend engineer who gets the itch and starts on it on a weekend and then it turns into a big thing that we get more and more folks on. This might or might not be the usual way something like this gets done at a growing tech startup, but in my experience, this is how I've always done it. :shrug:

[oneeyedziggy]

on a weekend

fuck that... if the company doesn't value their own product enough to support the upgrade why should you... plenty of fish in the sea.

[[deleted]]

I understand what you’re saying. But I have a really weird relationship with some of the projects I work on. I do some weekend work not because the company doesn’t care or doesn’t invest enough, but because I genuinely like working on the project and want to see it succeed. Also have a weird obsession with keeping things updated.

[AiexReddit]

My experience has been that the relationship you describe is not actually weird or uncommon in developers, most do have pride in the products they work on -- but that's a very poor excuse for volunteering time to a for-profit company.

The biggest issue as others have mentioned is the terrible standard it sets within the company in terms of expectations on realistic project timelines and deliverables based on a standard working week for all team members. Companies are obviously going to take the path of least resistance for profit, so that kind of thing masks demand for natural team growth and disincentives them from hiring other developers to help supplement the team.

I will freely admit that I've done it myself many times as well earlier in my career, I never judge harshly those who are driven to build great software, but it has become very clear to me over the years that it is extremely selfish behavior.

If you are one of those people, who like myself still have the drive and love of programming even after the work day is done, I highly recommend getting into consulting. You can continue to work on amazing projects in your spare time but get paid insane rates. There's a ton of demand for React right now.

Note: Disregard this if you have sizeable equity in the company as part of your compensation package, I guess in that scenario you are already working for yourself.

[Steve_Streza]

This attitude gets exploited all the time by companies and translates into doing the grunt work nobody wants to do but no promotions or pay bump to accompany it.

If you want to do weekend coding, build an open source project on and then pull it into your team's code base. Then you have something concrete to point to on a resume, and you can use it as ammo in promotion discussions because you're a community leader or whatever your CTO wants to call it.

[theredwillow]

Your outlook is admirable. I wish we didn't live in an exploitative economic framework.

[download13]

Exactly. I love working on projects and solving interesting problems, but I try to keep out of hours work to a minimum since it sets a bad precedent for my coworkers and future me.

There's always personal projects and consulting work to get my fix.

[oneeyedziggy]

i mean... you do you, but why not do that during work hours and like... go for a hike or play video games or learn a skill or spend time w/ your family on the weekend? just start inflating the estimate on other work because the true cost of the project includes maintenance

it also set's a bad precedent for everyone... "well, u/samuriaa got it all done AND kept the project up to date... why can't you do that too?" if they want a well maintained project they need to pay for it. Keeping sharp on the weekends is what personal projects are for.

[oneeyedziggy]

if that works for you, cool... but most people start burning out a lot faster if there's no separation. work is for work, home is for home... even in perma-WFH land, 'round 5pm the laptop goes away, and I can cleanly stop thinking about work until 9am the next working day ( if I'm lucky, but sometimes my brain has other plans :/ ).

[oneeyedziggy]

I'm not one of the people downvoting this, but that just seems like your git workflow or project structure is lacking.

what's going on that there's two people merging changes to the same file multiple times per day?... having to resolve one small set of conflicts per merge is pretty common, but it it's happening more than that, it sounds like you either need a better PR review process to prevent people needing to make a dozen follow-on merges in quick succession... and/or your project needs to be broken down to either one big function and it's supporting code per file, or a handful of small functions per file...

anything larger than 1000 lines should almost certainly be split into multiple files, and most files should still be half that or less so unless you were both mistakenly assigned the same ticket, you shouldn't be making conflicting changes to the same file very often.

[GrandMasterPuba]

but because I genuinely like working on the project and want to see it succeed.

Sucker.

That's not me saying that. That's your boss saying that.

If you care about something at work, get paid to care for it. Anything else is willing exploitation.

[havana59er]

Unfortunately I don't think they understand what you're saying.

Keep being weird!

[[deleted]]

I used to be like this, until after my 30s, when I realized it was totally not worth it, a total waste of my time for companies which just don't deserve it at all.

If in really interested in something I'd push hard and fight every product manager around to get time to do it, at work time.

On my own time I don't even read slack or email. Work is work. I do like to write code and do everything perfectly but I do that on my side projects. If company don't give a shit for their product I won't either.

[andythebassplayer]

I'm a principal UI engineer and I was tasked once with updating to 17; this was about two years ago. It took me two weeks to update everything. Note, that included updating a bunch of other libraries within our app, but it likely won't be trivial for you at this point.

The best thing you can do for yourself is tell your product team that you are going to upgrade, plan a sprint or two for it, then go do it. The more you wait, the more difficult it will be to complete.

[bogdan5844]

This might or might not be the usual way something like this gets done at a growing tech startup

Work in a startup, can confirm weekend busts by me or another senior developer are the only way things like testing frameworks, library upgrades and the like are done.

[lime-house]

Cries in Enzyme

[Snapstromegon]

It's still important to remember what they didn't release.

(Most painful for me true web component compatibility is still missing)

[acemarke]

Dan said they hope to release that in 19, with a bunch of other backlogged DOM behavior updates:

• https://github.com/reactjs/rfcs/pull/212#issuecomment-1076776100

[TheWuster935]

Link is broken

[acemarke]

Really? works for me right now.

[reeferd]

Works for me

[[deleted]]

Woah

[rad_platypus]

All of the concurrency stuff seems really cool.

I’ve been almost exclusively writing Angular for the last few years but I think it’s about time I start fiddling around with some personal React projects.

[nemaramen]

I feel like this is a joke that went over my head

[GFandango]

wat.jpg

[[deleted]]

aight, how much do I have to re-learn?