It is recommended to remove all control flow components

[sbfkcel]

It is recommended to remove all control flow components and do it as a pure function wrapper.

Officials should not provide these non-language standard custom components.

[atk]

Recommended by whom, wielding what authority over our framework and for what reason? Can you provide any source?

In any case, it's not mandatory to use them, they just make the code more readable than the alternatives.

[sbfkcel]

Sorry, maybe my expression is wrong.

I mean, the official should provide as few of these non-language standard components as possible.

The charm of React compared to other front-end frameworks is that it is closer to language standards. The Solid.js style is as close to React as possible, which is great.

And these non-language standard components make the writing style close to vue, and the application looks simple on the surface. But it takes extra memory, from my experience. I don't want to use a different framework to additionally memorize more stuff. This is very bad.

[lxsmnsyc]

Writing JSX code similarly how you write React code is okay, but is it recommended? Not really. The components provided by SolidJS delivers benefits such as performance. Things like keyed rendering in React doesn't exist in Solid so <For> aims to provide a way to make this possible while also allowing users to not think of how keys work and what keys they should provide.

IMO these are just a handful of features. If you are still having some memories of React stored I might have to recommend you to dispose them right away 😄 TBF React has more features that you need to memorize in comparison with the entirety of Solid.

[atk]

So your argument comes down to "it's not how I think it should be". Unfortunately, the way you suppose things to work could break reactivity in Solid.js, since mapping an array is basically destructuring it.

While you could still use mapArray or mapIndex to the same effect, it's easy to forget, thus we suggest the control flow components, because they are different enough not to trigger react reflexes.

[sbfkcel]

No, I don't want to break the Solid.js mind. I very much agree with the many features of Solid.js in terms of ease of use. Just a discussion, is it better to be closer to the javascript language itself?

E.g:

<For each={state.list} fallback={<div>Loading...</div>}>
  {(item) => <div>{item}</div>}
</For>

Change to pure function（schematic code）

{
    solidFor(state.list).each((item,index)=>{
        return <div>{item}</div>
    }).fallback(err => {
        return <div>{err.message}</div>
    })
}

or better purely functional way

[atk]

Rest assured our minds are sound and quite difficult to break. As I already remarked multiple times, solid has mapArray and mapIndex for the case you want a functional approach instead of using flow components and we have no qualms if you want to do so:

{mapArray(props.array || ['fallback'], (item) => <div>{item()}</div>)}

Thanks to tree shaking, there's no big drawbacks to this approach – except for developers with a react mindset being prone to forget to use them and use props.array.map instead, thus breaking reactivity.

So pleaseuse the functions instead of the flow components if that makes you happy, but stop asking for such an unnecessary breaking change.

[ryansolid]

There are 2 other things Components do that I like. Both around that we get to define the tracking context.

First of all both of these examples aren't good as you are missing a wrapper.. since as written you would trigger the whole expression re-running mapArray (or your For helper). It should be written like this:

// notice the function wrapper for reactive isolation
{mapArray(() => props.array || ['fallback'], (item) => <div>{item()}</div>)}

//or
{solidFor(() => state.list).each((item,index)=>{
      return <div>{item}</div>
}).fallback(err => {
      return <div>{err.message}</div>
})}

This extra wrapper isn't the end of the world but I wanted to point out that it is necessary and our JSX handles this for us.

Also related Solid's JSX transform has to assume every function call could be reactive and it makes an additional reactive wrapper here. Again basically free. But using components actually removes this unnecessary computation. Sure you could hoist it in some cases but you can't always. Components alleviate that immediately.

I've talked before about this but I also think that it reads better. I don't feel like digging it up but once your JSX blocks you return get larger the Component control flows it flows better, less of this in and out of context jumping thing parens game, especially for things like conditionals.

Components also are a nice container for these behaviors. Like React didn't need to use Components for Suspense or for Context Providers and yet they do. Error Boundaries are another. When you get into layouts this is pretty common too.

Finally people will mix flow logic with view logic so through composition you get to Components eventually anyway. Yes one could do this all with functions but that isn't where this tends to end up. Array.map does become <Paginate /> eventually. It's inevitable and starting here just sets the patterns from the start.

I guess that's 5 reasons.. not 2.