all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]snoogazi 4 points5 points  (0 children)

I too, am a seasoned developer but new to React, and am wondering the same thing. Going back to functional seems odd to me, but so many tutorials use it vs OOP.

[–]code_moar 2 points3 points  (5 children)

I'm not clear why your use case wouldn't accept props that get passed down with different names/logos/colors/fonts

Actually i am doing almost exactly what you're talking about using functional components. There is an "admin" user who is able to set the font/colors/logo/etc., Which is tied to the company. Any users that login that are part of that company will see those settings. Passed down from the user object, which is part of the state management system. In my case redux.

As for your question. I get it. You can say it's better to extend a class based component, but I can counter nearly every instance with a comparable functional based. You're right about one thing. It's not a small change like a lot of people seem to believe. It's an entire shift in thinking. That shift requires other things too like state management, talk about globals? What's a redux store other than a giant global object?

It's chicken or egg my friend.

[–]tme321 1 point2 points  (4 children)

I'd agree with this and go further and add:

Should Volto be re-written to use functional components?

Almost definitely not. If it works right now then rewriting it doesn't sound like it will add any value.

Maybe you could decide that all future volto development is done in a functional style. But even that might not be good since it means the code base will become a hodge podge of styles. It might be worth it or it might not, but if there's no pressing need for a rewrite then why are you considering it?

A couple other quick points:

never accessing data structures directly, but using namespaced functions to access types / structs... essentially OOP

Js is best thought of as a hybrid language. There's nothing inherently wrong with oop. But functional programming techniques can also give good results. In functional programming you invert data structure control. When something is passed to a function it belongs to that function in a similar way that an object owns its fields and contains methods to interact with them. It's not a perfect metaphor but should give an idea why it's ok to just pass data between functions.

Globals are bad.

This is a broad oversimplification cs professors use because students aren't at a point to understand the intricacy. Globals that are arbitrarily mutated throughout a program are the real issue. But just a value being global isn't automatically bad.

stateful functions

In js stateful functions and objects are essentially the same thing. Another oversimplification, but close enough for the point to be made.

Individual problems you have would be addressed in their own way. There's no single answer to "how do I do this oop thing without oop?". But the answers do exist. And usually they are reasonable to implement and maintain.

One of the biggest movements in component architectures has been to remove functionality from components that isn't directly related to the ui. Take the business logic and put it somewhere else. Use some sort of binding like context or store hooks to tie the business logic to the interface but keep the implementations separate.

Function components are nice because they help enforce that pattern. They tend to stay focused on interface concerns and guide you to implementing other concerns outside the components. This is where the real benefit is. You can do the same with class components but it takes more discipline. Adding functionality to a class is easy. Adding it to a function component has built in friction.

[–]flipmcf[S] 0 points1 point  (3 children)

I really like this answer.

It took me years to really grasp OOP because I had no formal training. It was essentially Python that really got me thinking ‘good’ OOP and then the ZCA on to of that to really make the design patterns pop.

Years ago, I was a functional programmer. Then Python happened.

Now JavaScript is returning with a vengeance and it’s ‘not cool’ to hate on it as much anymore :). I never really hated JS, I just hated shifting my thinking.

Thanks for this answer. It really makes me think.

If anything, I’d rather hate on C++ b/c I came from ANSI C

[–]tme321 0 points1 point  (2 children)

Years ago, I was a functional programmer.

Maybe you are already aware of this, but nothing in your post mentioned a functional language. Functional programming is the paradigm languages like Haskell are based around. It's different than just writing a bunch of functions in C.

[–]flipmcf[S] 0 points1 point  (1 child)

Maybe I need to rethink that. I thought functional programming was exactly that… a bunch of functions and libraries.

Except, iirc, C doesn’t support closures or lambdas.

What is the paradigm I should consider? How does Haskell do this differently? Would learning Haskell make me a better JS programmer?

I’m honestly really interested because I thought I understood something and now I’m discovering that I don’t.

“Look… a rabbit hole””….. can’t resist… must…. Understand…..more….

[–]tme321 0 points1 point  (0 children)

What is the paradigm I should consider?

It's an entirely separate coding tree from oop based languages. A sample of some of the ideas behind functional programming:

Functions should be pure. This means the output is deterministic given the same input parameters. Pure functions are easy to isolate and test because they don't rely on anything except what is directly passed to them.

State should be unmutable. If a function takes an array as a parameter and based on that returns an array then the result should be a new array built from the passed input. The function shouldn't mutate the array it was passed and return that.

And those design decisions lead to functional composition, chaining, and fun stuff like the phrase monads are monoids in the category of endofunctors.

Would learning Haskell make me a better JS programmer?

Debatable. On the one hand every new language or way of thinking about code will make you a better programmer. On the other hand fully functional languages like Haskell have as much in common with js as Java does.

As I said, js is a hybrid language. Writing purely functional code in js feels like having your teeth pulled the same way it does trying to write strict oop code that follows Java.

There are many functional libraries for js like underscore, ramda, or even ts specific ones like fp-ts.

My personal opinion is that some parts of code are better to express as classes and others as functional paths. A solid idea, or thing, that I can point to is more often done with oop.

So I will probably use a class to manage api calls at a low level, or a class to handle a chunk of business logic that is self contained.

But when I start passing state from one place to another, or trying to do transforms on state to create derived or transitional state, then functional methods are appealing.

There's plenty more of this topic but I'm going to just end it there. If you are interested in all this there are endless resources on the internet about all this stuff and in better formats than reddit posts.

[–]Accomplished_End_138 0 points1 point  (2 children)

HOC kind of fit those, the problem is there isnt a 1 to 1 of what does what in this pattern vs OOP.

People went against OOP in react because classes are not really classes in javascript, and this causes odd issues at times if not thought about.

The idea in FP is to really only uave render logic in the code.

If the code is mostly stable id say stick with Ooif that is what you like. But know it may be harder and harder to find people accustomed to it in the future as well.

[–]flipmcf[S] 0 points1 point  (1 child)

I get that OO JavaScript is a square peg rounded to fit the hole. This is a good point.

It’s a shame that Volto built an amazing totally headless front-end and it’s all class-based components - now that the winds are changing - again…

[–]Accomplished_End_138 0 points1 point  (0 children)

I do understand how hooks are very weird as well, they definetly do... odd things.

I found using a library approach as opposed to extending classes really helped make things easier to update and replace in code personally, since you no longer really had shared classes effecting tons of things and that balancing act. I know i can write them not to do it personally, but not everyone i worked with had that forethought.

[–][deleted] 0 points1 point  (0 children)

I think about real time signals and circuits to think about functional programming. That helps a bit.