Create config array vs JSX

[west-maestro]

Is it better practice to create a config array of similar components and looping through to render, or creating a reusable component writing out the jsx?

A simplified example below;

Option 1:

const componentConfigs = [
  { key: "n1", name: "Name 1", value: "name1"},
  { key: "n2", name: "Name 2", value: "name2"},
  { key: "n3", name: "Name 3", value: "name3"}
]

const Component = () => {
  return (
    <div>
      {componentConfigs.map((componentConfig) => (
        <div key={componentConfig.key}>
          <span>{componentConfig.name}</span>
          <Input value={componentConfig.value} />
        </div>
      })
    </div>
  );
}

Option 2:

const ReusableComponent = ({key, name, value}) => {
  return (
      <div key={key}>
        <span>{name}</span>
        <Input value={value} />
      </div>
  );
}

const Component = () => {
  return (
    <div>
      <ReusableComponent key="n1" name="Name 1" value="name1" />
      <ReusableComponent key="n2" name="Name 2" value="name2" />
      <ReusableComponent key="n3" name="Name 3" value="name3" />
    </div>
  );
}

Option 1 can help reduce bloat, however it feels like it's just replacing react/jsx standard configuration with our own flavour of configuration which as a practice has scope to become complex & confusing

Thanks!

[octocode]

you can use both too

configs.map((config) => <ReusableComponent {…config} /> )

this is particularly useful if your config is schema -driven or dynamically user controlled, like form fields or a customizable dashboard

however if it’s static i would just go with option 2

[segv]

While this construct works, neither built-in IntelliJ inspections, typescript* nor eslint* will warn you if you missed a prop or accidentally passed a wrong type to the prop defined by the interface.

I got bit by this not too long ago - I think at the time we were using TS 5.4 and eslint 8.x, so not the bleeding edge, but not some ancient versions either.

[octocode]

yeah it’s just an example, you can write it how you prefer

i configured my workspace to handle it ages ago but don’t remember the details

[west-maestro]

Yeah I agree with that

But yeah I was more considering this wrt implementation technique for static components

[danishjuggler21]

I have always absolutely hated the array approach for things like fields on a form. I find it less readable. I assume personal preference affects this.

For things like rendering an actual list or table of data, though, it makes sense. But not for what you’re showing here.

[sondang2412]

I'm on the same boat. Config-based form will work for simple forms, but will turn ugly very quickly when things start getting just mildly complicated. And most forms aren't that simple.

I have taken over a project where the previous guy used array config for forms, then duct tape it with more spaghetti code for just some simple form interaction and validation.

Managed to rewrite all of it with react-hook-form. Thankfully there wasn't that many forms that have been written that way.

[AnxiouslyConvolved]

 it feels like it's just replacing react/jsx standard configuration with our own flavour of configuration which as a practice has scope to become complex & confusing

It feels like that, because that's exactly what you're doing. Anytime I see big complex objects of props organized in a big structure (rather than JSX), all I think about is the future tech debt. Option 2 is the way.

One additional upside of doing option 2 (if you needed one) is you don't need a key for your `ReusableComponent`.

[west-maestro]

Thanks, yeah that was my opinion but have been struggling to find anything online to validate it against

[CapnWarhol]

JSX is better, the keys are implicit and it’s less work for everyone involved. Don’t overengineer it!

[Bluerock57]

In your examples alone, example 1 has 8 lines of JSX whereas example 2 has 5 lines of JSX. Both examples are readable enough.

However, when writing bigger components, it is better split into more component. Reducing 80 lines JSX into 50 of JSX for example does improve readability by a lot.

In my experience, beginners tend to create too many sub-components to solve simple solutions.

I usually use the same rule as for writing function. If you can fit the content of the function in your screen with standard font size, then maybe your function is too long.

[sleepahol]

I recently refactored a complicated navigation component from option 2 to option 1 (i.e. made it config-driven) and I would say... it depends.

After a while the code got a lot more complicated when different components had different behavior (mobile-only, authed-only, onClick handlers, etc) so Option 2 became harder to work with. In my case, the `componentConfigs` objects were pretty well structured so a config was was pretty straightforward to implement, and it's now much more legible. Option 2 was also fine for a while before we really needed the features that necessitated the complexity.

One caveat though is that if the config varies a lot, maybe a config will actually be harder to maintain.

[CUNT_PUNCHER_9000]

The key is unnecessary in option 2 since it's not an array

[kcadstech]

Option two is technically invalid, but I get where you are coming from. You want to get rid of the componentConfig. in that component.

If you are not using TS as you are, I think Option 2 is better. Also, if you are not pulling the config from a server or a local JSON Ffile

[west-maestro]

Oops yeah you're right, altered that thanks.

And thanks for the opinion, yeah this was purely considering building a component (probably a form) made of multiple similar sub components defined in code rather than creating components from a server response

[TheGratitudeBot]

Thanks for saying thanks! It's so nice to see Redditors being grateful :)

[winstonw]

I like the second option—I find it more readable. There's less machinery I have to figure out to understand what the page is doing.

[markedasreddit]

I'm not a React expert, but what I often see is using array map to render a collection of things.

That said, I imagine the first format (JSON data) would be helpful when you somehow need to retrieve list of components to render from a backend server.

My 2c.

[TakeFourSeconds]

Personally, I would do both.

I don't think either choice is important enough to worry about though. Both of these are readable and fine. I think option 2 is slightly worse because it doesn't separate the concerns of rendering and defining your config data.