Hacker News new | ask | show | jobs
by ellius 2314 days ago
Bounced around 2 projects in the last 12 months, one Angular and one React, that are using the Flux pattern. It is a real bitch to unit test anything but the individual pieces, which ends up being kind of meaningless.
3 comments

I love React, but this (and forms) is the bane of my life. I've started to unit-test my frontend a lot, lot less and rely on a lot of e2e tests. Cypress is great and I trust my app more to actually work when a user uses it
> unit test anything but the individual pieces

Isn't that the definition of a unit test?

Debatable but I get your point. The thing is that Flux is a pattern, and you often want to test the full pattern to get a meaningful "unit" of behavior/logic. There can be meaningful logic in the individual pieces, but frequently they only make sense as a whole.
It's not debatable...

Unit tests are for testing individual components of your application (web or otherwise)

e2e or integration tests are for testing your application component/lib/api/whatever boundaries

Sure, but what do you count as a "component"? It varies by language, framework, platform, and pattern.
How do you test individual components in isolation if they depend on the global state store?
That's a code smell. 99% of components in a project should rely on props.
How does that play with Redux Hooks for example? https://react-redux.js.org/next/api/hooks

If you are using hooks in your components, you need the global store instance. To call this unit testing is too big a stretch for me.

Please explain the flux pattern?
See the docs for the original Flux Architecture:

https://facebook.github.io/flux/docs/in-depth-overview

Redux was originally designed as a Flux implementation:

https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

From that Facebook article: Flux eschews MVC in favor of a unidirectional data flow.

This is so incorrect. MVC doesn't imply two-way data binding. The whole Flux architecture was based on a misunderstanding of MVC, and is therefore questionable.

Most UI frameworks, including iOS, ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC.

Why is it that MVC works for all these other frameworks, but doesn't for React? The answer is that MVC does in fact work for React. React itself originally used the tagline "React is the V in MVC". Flux/Redux introduce needless complexity and unnecessary boilerplate. There are MVC libs that make React much easier to use.

> iOS, ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC.

Don't all of those have two-way data binding?

> Why is it that MVC works for all these other frameworks, but doesn't for React?

I think the point is that Facebook found it doesn't actually work well, at least for their use cases. They found a recurring set of bugs caused by two-way data flow, and built a framework to alleviate it.

> Don't all of those have two-way data binding?

No they don't.

> I think the point is that Facebook found it doesn't actually work well, at least for their use cases. They found a recurring set of bugs caused by two-way data flow, and built a framework to alleviate it.

But MVC doesn't mean two-way data flow.