3 ms·

> Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name. I definitely haven't been fol

> Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name. I definitely haven't been following this... anybody else using nearly 99% of functions in their frontend work? (Typically I'm in the React TypeScript world)

rablackburn 5y ago
I’m from the same world as you and here’s how I understood this: Any function that’s not pure should be a ~class~ component. ie, when you have a bunch of functions that operate on the same kind of struct/set of state, and in fact you want to prevent other functions from messing with it (you want to make it internal), you group them in some way. The OO word for that is a class. React is a component; which are much more composable because we ditched the stricter concept of inheritance of OO classes. Hell, the es6 class system is really just syntactic sugar around Brendan Eich’s nifty prototypal system. If it weren’t for the weak typing and lack of std.lib, JavaScript would be an amazing language. …which is to say it would probably be Go haha
- fullstackchris 5y ago
  But what about hooks? These essentially break this point completely. Functions that literally have (side) 'effect' in the name! (useEffect) Over the past few years, at least on the frontend, I've found in every case what is a class could be expressed in a function or variety of functions. So yeah, still unsure about this point, maybe it was more for other software domains (backend, embedded, etc) Funny too about what you say about 'grouping functions in some way'... I just made a post about how it makes a lot of sense to put a single function per file... with my organizing, a named folder is the only thing that 'groups' my functions together... so far this style of organization is working well for us. https://chrisfrewin.medium.com/advanced-code-organization-patterns-the-case-for-one-function-per-file-da68c15826e8 https://chrisfrewin.medium.com/advanced-code-organization-pa...

rablackburn 5y ago

I’m from the same world as you and here’s how I understood this: Any function that’s not pure should be a ~class~ component. ie, when you have a bunch of functions that operate on the same kind of struct/set of state, and in fact you want to prevent other functions from messing with it (you want to make it internal), you group them in some way. The OO word for that is a class. React is a component; which are much more composable because we ditched the stricter concept of inheritance of OO classes. Hell, the es6 class system is really just syntactic sugar around Brendan Eich’s nifty prototypal system. If it weren’t for the weak typing and lack of std.lib, JavaScript would be an amazing language. …which is to say it would probably be Go haha

fullstackchris 5y ago
But what about hooks? These essentially break this point completely. Functions that literally have (side) 'effect' in the name! (useEffect) Over the past few years, at least on the frontend, I've found in every case what is a class could be expressed in a function or variety of functions. So yeah, still unsure about this point, maybe it was more for other software domains (backend, embedded, etc) Funny too about what you say about 'grouping functions in some way'... I just made a post about how it makes a lot of sense to put a single function per file... with my organizing, a named folder is the only thing that 'groups' my functions together... so far this style of organization is working well for us. https://chrisfrewin.medium.com/advanced-code-organization-patterns-the-case-for-one-function-per-file-da68c15826e8 https://chrisfrewin.medium.com/advanced-code-organization-pa...