[HN Gopher] Four approaches to implicit state in compound compon...
___________________________________________________________________
Four approaches to implicit state in compound components, ranked
Author : genericlemon24
Score : 34 points
Date : 2021-06-27 09:04 UTC (1 days ago)
(HTM) web link (jesseduffield.com)
(TXT) w3m dump (jesseduffield.com)
| [deleted]
| stupidcar wrote:
| These are all terrible, and they all stem from TypeScript's
| inability to properly restrict the type of JSX children.
| Something that's been an issue for years with no sign of
| resolution, because the proposed fix (from a member of the TS
| team) has terrible performance:
| https://github.com/microsoft/TypeScript/issues/21699
|
| But since React is a such a minor part of the JS/TS landscape,
| who can really blame the TS team for not prioritising this,
| right!?
| ssijak wrote:
| Are they really that _terrible_?
| runawaybottle wrote:
| It's scary that the author examined four ways to do a pretty
| simple component. Nothing wrong with that, but the horror happens
| when a more abstract component falls into the lap of a React
| developer. The permutations in which one can build a app specific
| component (not a baseline ui component) is a pretty large number.
|
| If we start applying our perceived values to anything more
| complex, we increase complexity (death via virtue). I'd argue
| that we should seek out a scaleable virtue system. While some of
| those cases that were grade A can be proven to be proper in
| simple components, they become unwieldy in larger component
| systems if we pursue righteousness like zealots.
| asah wrote:
| omg this. But I'm curious, you got any nice counter-examples of
| _lively_ ecosystems that maintained a reasonable number of
| permutations? (I do agree that JS has been the wild wild west
| for a decade too long, and the mobile revolution is no excuse
| for silliness that should 've been resolved in the 2000s)
| runawaybottle wrote:
| _But I 'm curious, you got any nice counter-examples of
| lively ecosystems that maintained a reasonable number of
| permutations?_
|
| Nope. We all suffer together.
| barbarbar wrote:
| It would be very nice to compare the solutions with a html
| approach like https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/de...
| runawaybottle wrote:
| I'm going to sound hyperbolic, but your suggestion is profound.
| I mean, look at that thing, and look at the React examples.
| jaywalk wrote:
| They are barely the same thing.
| asah wrote:
| Is this the same thing? I didn't see an obvious way to close
| the other details when one of them is opened...
| rendall wrote:
| Software is eating the world, and React is eating software
| barbarbar wrote:
| Yes you are right. I am trying to like React. It doesn't go
| too well. And when I look at it again they have invented a
| new concept. Like here useSomething or useThisOther.
| rendall wrote:
| I do not like React, but I recognize it as the tool it is.
| It is possible not to like it and still be competent in it.
| Blahah wrote:
| The inclusive components approach is rather beautiful. No
| frameworks (so it works in all frameworks that are standards
| compliant), and it is accessible and semantic:
|
| - https://inclusive-components.design/collapsible-sections/.
|
| Github's elements collection (custom elements/web components)
| includes several beautifully implemented `details` based
| approaches to UI problem:
|
| - https://github.com/github/github-elements
|
| Doing this stuff in React is really quite over-complicating it
| (and making it practically less accessible/reusable). React is
| uniquely bad for the web among the most popular frameworks:
|
| - https://custom-elements-everywhere.com/
| nawgz wrote:
| > Doing this stuff in React is really quite over-complicating
| it (and making it practically less accessible/reusable)
|
| I find it hard to understand how implementing components
| within a framework your entire company presumably uses would
| "[make] it practically less accessible/reusable". I
| especially take issue with the word "practically", as I can
| see from some theoretical point of view that an HTML-only
| component would "enable reuse across all frameworks", but
| practically speaking I never see people mix frameworks,
| because that of course would be horrible for performance and
| real-world reuse.
| Blahah wrote:
| Good points, I was specifically thinking about open source
| components. I use Web components in various frameworks all
| the time.
| svieira wrote:
| Doesn't include the seapig approach!
|
| Using the grading framework here, it's probably a C. Looks good,
| lots of flexibility for the component consumer. Bad TS support,
| plus the same problems as cloneElement. But I think it's a nifty
| pattern anyway.
|
| https://github.com/enkidevs/seapig
| runawaybottle wrote:
| Seaping looks pretty good, thanks for sharing.
| camgunz wrote:
| This post feels a little odd. Spreading state across multiple
| (compound) components isn't wonderful; that's what controllers or
| stores are for.
|
| But also this example doesn't need to do that? All the complexity
| is from the contrived requirement that the accordion sections
| themselves can be arbitrary nodes. If you just said "this has to
| be text and we're wrapping it in a <p>", there's no need for a
| component tree here. And besides, it's not like you can just pop
| anything in there--you'll likely break your layout if you try.
| nawgz wrote:
| > the contrived requirement that the accordion sections
| themselves can be arbitrary nodes
|
| Why is that contrived? I implement complex forms as data input
| for a workflow runner. Often, there are nested properties only
| relevant for certain branches of workflows, and to keep the new
| user's focus and eye, I put these properties within an
| Accordion. They include classic data inputs as well as tree-
| browsers for file or other tree structures, arbitrary lists of
| objects, etc.. It is quite graceful
|
| > it's not like you can just pop anything in there--you'll
| likely break your layout if you try
|
| And this is where I grow even further confused. It's exactly
| like you can pop anything in there - otherwise why did I
| implement an Accordion in the first place? My layout tracks the
| scrollHeight of the container node holding the children for
| each section and updates & animates its own size accordingly.
| It's of course just a flex-column, but maybe you can enlighten
| me on something I am missing with regards to your comment and
| this implementation.
| edoceo wrote:
| The contrived requirement was just to provide an example with
| some state-y thing that is easy to grok.
___________________________________________________________________
(page generated 2021-06-28 23:02 UTC)