Hacker News Reader

Comment by ojkelly | Hacker News Reader

You can build serious UI’s without useEffect.

But it’s a powerful escape hatch like rust’s `unsafe` block. Rust can do amazing things to ensure safety of your program, but there’s still times where a human can do it better.

By signposting that, keeping it to limited blocks, and wrapping it up in a safe function you get the capability to do hard things, while exposing a safer API.

useEffect is similar, it lets you write the imperative synchronisation logic. For example if you need to interact with a DOM element that only has an imperative API, someone needs to do the work somewhere to wrap it in a declarative one. You can do that in a component with a useEffect hook, and then expose a declarative API.

View on HN

It's still using the useEffect hook, but just wrapped in a useFetch or something. So technically you're not building a UI without useEffect, just hiding it, no?

How far down the rabbit hole do we need to go?

Because at some point your function call is manipulating registers on the CPU. If we go even further, the CPU needs to load its next instructions and then the data required.

Point being, we abstract and encapsulate complexity and provide a simpler API around it. It’s the only feasible way to manage the inherent complexity.

React builds up a virtual description of UI. react-dom and react native take that description and synchronise it to the UI layer.

If you need to do something extra, that they don’t handle like managing a map widget (ie mapbox) in React that only has an imperative API, it sure would be nice to do that yourself.

You can build a UI without useEffect. You can hide messy implementation details inside a well tested component, and contain where useEffect is being used.

And, you can understand how useEffect works so that you can use it without it having a negative effect on you.

It's just that "You can build a UI without useEffect."

and

"You can ... contain where useEffect is being used."

are not the same statement. Maybe I'm being pedantic, but when I read "build without X", I think there is some method that can be used to avoid X, not that I can hide away X.

They’re not the same statement. Both are correct. But as always, the nuance is critical.

All declarative code eventually runs something imperative.

And anything non-theoretical is going to have side effects somewhere.

Painting to a screen is a side effect.

Reading a file is a side effect.

Software gets messy when it intersects reality.

But, we can do quite a lot by staying in a theoretical realm. You can build a whole UI in the theoretical realm, where no side effects exist.

When you actually need to run it though, you drop out the the theoretical and into reality. Now there’s side effect’s everywhere.

So you contain them. Encapsulate those side effects into composable blocks. Test them extensively. Offload that work to someone who’s just focussed on managing them.

Updating the DOM is a side effect. Making a network request is a side effect.

Contain them, test them, and then you can stop thinking about them.

If someone else has done all the work to contain side effects, you can build a UI without them.

Reply on news.ycombinator.com