On first scan, it's using a render function for items - which is fine, but I think it still has cognitive dissonance as you reason with the parameters of the render function and figure out the key on the item. I'm in JSX, I'm about to write some more JSX, I don't need this render function is my personal preference.
My full implementation of this allows for that approach (and multiple functional children if you like!) but if I look at the code where we use our function, it never actually happens. All we ever use is the item={<SomeRenderer/>} because it covers off all of our requirements and the code scans better.
Repeat with auto keying and debug fall back to JSON is 29 lines of code. I wouldn't make an npm package out of that :) I'd write a Dev article LOL!
But it has a trouble problem that in TS: the item needs to define a variable separately to match the TS type.
I feel that the approach of react-loops, which maybe has a higher recognition, because it uses the render props pattern commonly used in React. For example, solidjs also uses this <For> design: solidjs.com/docs/latest/api#%3Cfor%3E
After reading your article, I think it's certainly useful. I just feel that at first glance, there is a lot of code, which is a little complex for people who see it for the first time, perhaps it would be better to have a simplified version. Thanks for sharing~
I mean, you would have the actual function in a utilities file and it's only a few lines of code. It works fine in TS. Here's an example of Repeat written that way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How about this approach? github.com/leebyron/react-loops
Thanks, not seen that one!
On first scan, it's using a render function for items - which is fine, but I think it still has cognitive dissonance as you reason with the parameters of the render function and figure out the
keyon the item. I'm in JSX, I'm about to write some more JSX, I don't need this render function is my personal preference.My full implementation of this allows for that approach (and multiple functional children if you like!) but if I look at the code where we use our function, it never actually happens. All we ever use is the
item={<SomeRenderer/>}because it covers off all of our requirements and the code scans better.Repeat with auto keying and debug fall back to JSON is 29 lines of code. I wouldn't make an npm package out of that :) I'd write a Dev article LOL!
Oh, I basically understand, thanks for your detailed reply.
For the approach without render function, I also have seen this: github.com/AlexGilleran/jsx-contro...
But it has a trouble problem that in TS: the
itemneeds to define a variable separately to match the TS type.I feel that the approach of
react-loops, which maybe has a higher recognition, because it uses therender props patterncommonly used in React. For example,solidjsalso uses this<For>design: solidjs.com/docs/latest/api#%3Cfor%3EAfter reading your article, I think it's certainly useful. I just feel that at first glance, there is a lot of code, which is a little complex for people who see it for the first time, perhaps it would be better to have a simplified version. Thanks for sharing~
I mean, you would have the actual function in a utilities file and it's only a few lines of code. It works fine in TS. Here's an example of Repeat written that way.