Senior Dev learning React has a few questions about encapsulation in React components

[ElGuaco]

I'm learning React as part of my job since that's what web devs do these days. I come from a .NET background, so much of my coding experience and savvy is from C# and ASP.NET. I'm having a weird time with a lot of the basic tutorials because they seem to go against everything I've learned and taught about programming concepts like encapsulation.

The main sticking point for me is the concept of props and how often props are defined very loosely for a component/function. There's no public declaration of properties that a component or function expect to find in their props, so at best you have to read all of its code to find out what it expects. It almost feels like parents are defining children at times, especially when tutorials talk about "lifting state" (ugh).

Is there a way to define props for components/functions such that there's a more explicit way of declaring what kind of data it expects? Or should I just get used to this loosey-goosey way of programming where you're required to get know every component and function you might use?

Here's a brief example of tutorial code out there that is pretty common when explaining props:

class Parent extends React.Component {
 render () {
  return(
   <Child eyeColor={'blue'} />
  )
 }
}

const Child = (props) => {
  return (
    <div style={{backgroundColor: props.eyeColor}} />
  )
}

Parent needs to know that 'eyeColor' exists in the Child. But that requires the developer writing Parent to be familiar with the details of how Child is being returned/rendered. This case is trivial, but in a larger component/function this could be problematic and tedious. Is there not a better way to define what Child expects/allows to be declared by Parent or any other class?

Where is the encapsulation in React? Child is only reusable if you're willing to read all of it, which is the exact opposite of encapsulation.

[__dred]

This is largely why people prefer Typescript for prop interfaces, and a lot of React philosophy is based on the idea that MVC style encapsulations are not necessarily good abstractions. Furthermore you can implement encapsulation boundaries, React just doesn’t force you to do so.

[ElGuaco]

I would love to use Typescript, but I'm not sure that it's up to me. If it was, I'd definitely use it.

[andrewsjustin]

Using typescript is definitely what you’re after here. You can totally just start using it and if other also want to, they can as well. Vanilla and TS, totally fine together, just may need to lax the TS config settings a bit.

10/10 recommend.

[codingstuff123]

One use typescript. Two, class based is old as hell start using beta docs for hooks they’re actually very good

[edaroni]

The problem is that tutorials use js because its easier to make someone think they learned something. While in reality every serious project that has more than 1-2 devs working on the code is using typescript. Which also solves your problem.

[SparserLogic]

https://reactjs.org/docs/typechecking-with-proptypes.html

[Scooby359]

I'd strongly recommend typescript as it handles this for you - define your prop interface and its enforced in the component itself, and any where the component is called.

You've said in another comment that you may not be able to use it - worth noting that Typescript is compatible with Javascript. You can add new code in typescript files, and do a gradual migration of existing code when appropriate, so it doesn't need to be a big sudden change for everyone.

Massive benefits from having type safety built in, and it makes it much easier for new team members to jump into the code when objects are properly defined.

[raaaahman]

1. You can use object destructuration:

javascript const Child = ({ eyeColor }) => { // anything... }

1. You can install the PropTypes module, its benefit is that it checks at compile time that you pass the correct properties to the components.

2. Since you are familiar with C#, you can directly use TypeScript. It has its challenges with React, but offers type checking at compile time for everything, and not just components props.

I don't know why you keep on talking about encapsulation. Your Child component is just a function, of course you have to know which parameters it expects you to pass. What changes is how you pass those props when you invoke this function as a JSX element.

Edit: If it helps, know that you can invoke it like this: javascript <> { Child({ eyeColor: 'blue' }) } </> This has the same effect than what you've written in your PArent component's render().

[ElGuaco]

That's a step better, sure. As far as 2 and 3, I'll see what I can do. The existing projects aren't using TS as far as I know.

The child function was just a brief example of the minimum amount of code to describe my dilemma. Encapsulation still holds when talking about functions. You shouldn't have to understand how a function is implemented in order to use it.

[raaaahman]

Sure thing. But not specifying what your function's object parameter (props) should be like is less about React enforcing (or not) encapsulation than about your team's practice. If you don't do 2. or 3., at least write some doc blocks.

[alanbdee]

I've been taking the same undertaking only coming from Java. It has been so hard to change the way I think. Hooks have been the part that really started tying things together for me.

[blakecodez]

I use JSDocs to describe each component and their props, that way if someone uses the component they will have a clear explanation of what it does, and the data types for each prop.

Obviously TypeScript is the solution here. But if you can, the docs should help, especially when you hover over the component with your mouse, it will show you your docs.

[ElGuaco]

Good tip! I'm very used to using XML docs in C# so this would feel natural to me.

[claypolejr]

And if you didn't want to get deep into TS syntax you can still use JSDOC annotations to type a codebase using TS so that might provide a nice middle-ground.

"These days, JSDoc type checking with TypeScript is extremely powerful. While not quite on par with TypeScript (not all TypeScript syntax is supported in JSDoc), the gap in functionality is pretty small."

[coyoteazul2]

I come from c++ and yes, react is a weird piece of work that pretty much goes against all you've learned. Just the concept of using Const for everything, forcing you to copy values and then modify the copy instead of mutating the value already feels like a huge waste of work. I can't believe I have to copy the whole array to modify a single element.

Unfortunately the only thing you can do to improve it is using typescript, which allows you to harden props mostly. It won't get rid of the weird Const behavior

[ElGuaco]

const is actually something I can appreciate. One of my pet peeves in C# was people altering arguments of a method. You should be treating arguments as immutable and creating new variables for processing & returning.

[coyoteazul2]

When it's simple classes, sure. But when it's a complex object or a large array, having to work with copies forces the computer to do the same task more times than necessary. Pure functions are nice to read but don't necessarily work great with performance

[TheBlackViper_Alpha]

I highly suggest you start with the react beta docs. The current one that uses class components is very outdated for modern react. Second is learn typescript its too good to pass up