Skip to content

Add Truncated Definition List#10292

Merged
brad-decker merged 4 commits intodevelopfrom
add-truncated-definition-list
Jan 28, 2021
Merged

Add Truncated Definition List#10292
brad-decker merged 4 commits intodevelopfrom
add-truncated-definition-list

Conversation

@brad-decker
Copy link
Copy Markdown
Contributor

@brad-decker brad-decker commented Jan 26, 2021

Requires: #10289, #10291

Rationale

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

@metamaskbot
Copy link
Copy Markdown
Collaborator

Builds ready [9e53d69]
Page Load Metrics (607 ± 56 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint448257115
domContentLoaded38982660511756
load39082760711756
domInteractive38982660511756

Base automatically changed from add-definition-list to develop January 28, 2021 15:54
@brad-decker brad-decker force-pushed the add-truncated-definition-list branch from 9e53d69 to c8f1c8f Compare January 28, 2021 16:00
@metamaskbot
Copy link
Copy Markdown
Collaborator

Builds ready [c8f1c8f]
Page Load Metrics (681 ± 42 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint498663105
domContentLoaded4328026808742
load4328036818742
domInteractive4318026798742

@brad-decker brad-decker marked this pull request as ready for review January 28, 2021 16:33
@brad-decker brad-decker requested a review from a team as a code owner January 28, 2021 16:33
@brad-decker brad-decker requested a review from Gudahtt January 28, 2021 16:33
@Gudahtt
Copy link
Copy Markdown
Member

Gudahtt commented Jan 28, 2021

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.

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 null. It seems simpler to leave that responsibility with the parent component, rather than divide it between the two.

@metamaskbot
Copy link
Copy Markdown
Collaborator

Builds ready [8cad627]
Page Load Metrics (1249 ± 49 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaintNaNNaNNaNNaNNaN
domContentLoaded1106152412449747
load11091547124910149
domInteractive1105152412439847

@brad-decker
Copy link
Copy Markdown
Contributor Author

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 null. It seems simpler to leave that responsibility with the parent component, rather than divide it between the two.

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.

@Gudahtt
Copy link
Copy Markdown
Member

Gudahtt commented Jan 28, 2021

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.

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.

Copy link
Copy Markdown
Member

@Gudahtt Gudahtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@brad-decker
Copy link
Copy Markdown
Contributor Author

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".

@metamaskbot
Copy link
Copy Markdown
Collaborator

Builds ready [df6c5f2]
Page Load Metrics (612 ± 70 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint469164115
domContentLoaded401110561014770
load402110661214670
domInteractive401110561014770

@brad-decker brad-decker merged commit 471140f into develop Jan 28, 2021
@brad-decker brad-decker deleted the add-truncated-definition-list branch January 28, 2021 17:22
@github-actions github-actions bot locked and limited conversation to collaborators Jan 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants