re: Class Components vs. Stateless Functional Components VIEW POST

VIEW FULL DISCUSSION
 

If your function takes inputs then it's not stateless, technically. Maybe you mean "side-effect free" in which case I think you can make class components side-effect free as well and the distinction disappears.

 

Touché. Typically, the nomenclature I see around this is “stateless functional components” so I figured i’d stick with it.

 

I can sometimes be a stickler for precise technical language so don't mind me. The JavaScript ecosystem gave us "isomorphic JavaScript" which to this day I don't understand.

Sticking to community nomenclature is fine if that's what the community has settled on.

Isomorphic just means 'same shape's so it should be the same shape code on both server and client.

I know what the word means formally. I studied pure math in college and grad school. The word is poorly chosen for what it means in the JavaScript ecosystem. They should have used "portable" instead of co-opting a formal mathematical term.

Hey, that's great — not doubting you. Portable tends to be used for software that doesn't need to be recompiled for different machines.

No words going to be perfect though.

 
 

I mean it doesn't print to console, write to a file, increment some variable somewhere, etc. The output depends only on the inputs.

 

In the context of React “Stateless Functional Component (SFC)” is actually the correct term. There is a documented difference between properties and state. While all components in React may take input, that input is always referred to as properties. State is specifically data that a component manages internally. SFCs are thus named due to their inability to possess/manage state.

Technically, one could return a closure and manage state in a SFC, but that would be unusual.

code of conduct - report abuse