DEV Community

loading...

What's your opinion on data-first frontend ?

joon
Interested in: Blockchain, React, Nextjs, Anything front-end. Handling high-frequency data efficiently & gracefully
・2 min read

Read first

2 years into my front-end career, I'm handling projects that I really feel like I need to be studying hard CONSTANTLY in order to reduce technical debt to a minimum.
And then I come across this post which almost convinced me it's the right way to go.

It's time for a revolution in data-first frontend frameworks, which relegate React to what it does best: rendering and diffing DOM nodes. Values in, actions out. No useState. No useEffect.

...

It's time for a change. It's time for a paradigm shift. It's time for a revolution in data-first frontend frameworks that control the view layer and not the other way around.

Reading the above 2 paragraphs, I was almost convinced I needed to refactor everything in order to make this possible.

The topic is not whether Kea is the framework to use - but whether this is the right mindset. Throughout my career, my coding style focused on trying to keep as much of the application state non-global as possible. This post was challenging the very fiber of the thought-process I've been trying to perfect through my frontend career.

From that moment forward, I would see this everywhere. If ever I felt like my program was getting too complicated or hard to read, it was almost always a data structure problem

This part honestly - I agree 110%. It actually feels exactly like the state of a project that is increasingly getting harder to develop / maintain.

But is this what I should be focusing on?

Since my thought process has started to really jump out of the box, maybe I'm focusing on the first seemingly radical idea that I randomly came across that seemingly fits?

Namely,
Is this Input-Data-View layer parallel hierarchy the way to go?

What are your thoughts?

Discussion (2)

Collapse
jackmellis profile image
Jack

Yes. In my experience, useState / useEffect should be reserved for ui state only. Your application state (and general domain logic) should be kept as far away from your presentation layer as possible.

The crazy thing is, we'd developed all of these practices when redux was king. When hooks arrived, we abandoned everything and started throwing state everywhere, and now we're having to re-learn how to write sensible application state again.

Collapse
fly profile image
joon Author • Edited

When hooks arrived, we abandoned everything and started throwing state everywhere

I agree with this so much. I never really realized how disorganized my projects were becoming until I started to handle high profile ones that had relatively complex data structures and streams of data to take care of.