Is using ES6 classes in vue/vuex(/flux?) an anti-pattern?

Question

I've been using Vuex, and it's adherence to only altering state through it's mutators or actions makes me think your store should only include as flat an object as you can, with only primitives types.

Some threads even prescribe normalising your data (so instead of nested object trees you have objects with arrays of id's to indicate tree relationships). This probably matches closely to your JSON api.

This makes me think that storing classes (that may have methods to alter themselves) in your flux store is an anti-pattern. Indeed even hydrating your store's data into a class seems like you're moving against the tide unless your class performs no modifications to its internal data.

Which then got me thinking, is using any class in a Vue/Vuex/Reactive/Flux an anti-pattern?

The libraries seem explicitly designed to work with plain JS objects and the general interactions you have with the API (data in, data out) makes me feel like a more functional approach (sans immutability) is what the original designers were thinking about.

It also seems be easier to write code that runs from function => test => state mutator wrapper around function.

I understand that JS objects and JS classes behave very similarly (and are basically the same thing), but my logic is if you don't design with classes in mind, then you're more likely to not pollute your state with non-flux state changes.

Is there a general consensus in the community that your flux code should be more functional and less object orientated?

Dismissal

On a side note, this is a good question. – Tight

I think this would be a better fit for softwareengineering.stackexchange.com since this is a question about software methodology. – Overtire

Answer 1

Yes. You are absolutely right in what you are thinking. State containers like Redux, Vuex are supposed to hold your data constructs and not functions. It is true that functions in JavaScript are simply objects which are callable. You can store static data on functions too. But that still doesn't qualify as pure data. It is also for this same reason that we don't put Symbols in our state containers.

Coming back to the ES classes, as long as you are using classes as POJO i.e. only to store data then you are free to use those. But why have classes if you can have simple plain objects.

Separating data from UI components and moving it into state containers has fundamental roots in functional programming. Most of the strict functional languages like Haskell, Elm, OCaml or even Elixir/Erlang work this way. This provides strong reasoning about your data flows in your application. Additionally, this is complemented by the fact that, in these languages, data is immutable. And, thus there is no place for stateful Class like construct.

With JavaScript since things are inherently mutable, the boundaries are a bit blur and it is hard to define good practices.

Finally, as a community, there is no definite consensus about using the functional way, but it seems that the community is heading towards more functional, stateless component approaches. Some of the great examples are:

• Elm
• ReasonML
• Hybrids
• swiss-element
• Cycle.js

And now, even we have functional components in both Vue and React.

Tight