Conversation
Builds ready [9e53d69]
Page Load Metrics (607 ± 56 ms)
|
3127e33 to
8697a0e
Compare
9e53d69 to
c8f1c8f
Compare
Builds ready [c8f1c8f]
Page Load Metrics (681 ± 42 ms)
|
What was the reason for this change? I don't really follow why it would be desirable for a component to instantiate itself only to render |
ui/app/components/ui/truncated-definition-list/truncated-definition-list.js
Outdated
Show resolved
Hide resolved
ui/app/components/ui/truncated-definition-list/truncated-definition-list.js
Outdated
Show resolved
Hide resolved
Builds ready [8cad627]
Page Load Metrics (1249 ± 49 ms)
|
I'll confess that this is more of a personal preference than any design-driven decision. My only (weak/weakly held) argument would be that with the open prop the popover itself holds all of the code related to its state (visible/not visible) versus that attribute being controlled by the parent. I don't find it important enough not to remove, though. |
Huh, that's interesting. I believe the exact opposite of this, and it's the sole reason that I don't prefer this pattern 😅 The way I see it, the decision for whether to render something is always in the parent. The parent decides what to render and when; you have to check there anyway when reading code to see whether something is rendered. Moving this logic into the child component splits that logic up between two places, rather than one. |
|
I mean, any controlled component behaves based on the props that you pass it. For example, you pass a controlled input the text you want it to display and the methods for updating the text, but the input controls how it renders the text and hooks up the methods. My experience comes from Material-UI and derivatives that provide "Modal" and "Popover" components all of which accept an open prop, but admittedly there's so much more going on under the hood with those things. In fact, now that I've looked at what they're doing I'm very happy to be in the land of "just conditionally render the thing". |
Builds ready [df6c5f2]
Page Load Metrics (612 ± 70 ms)
|
Requires:
#10289,#10291Rationale
The new custom network UI calls for a definition list that has a few important keys visible, with others viewable in a popover summoned by clicking a "View all details" button. This "Truncated Definition List" component makes this functionality reusable, by supplying an array of keys that should be viewable on the main screen.
Quasi-related changes
Popovers are normally rendered conditionally, instead of passing an 'open' prop to them to allow the main component to handle whether the contents / overlay should be rendered or not. I revised this but left it such that open is the default. This will preserve the behavior of Popover everywhere else in the app.Examples
use prefaceKeys to control which terms to display
All terms displayed in popover