question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Consider removing prop spreading from VRT output

See original GitHub issue

Summary

Right now, we show all of the props of the direct child of a Spec in our visual regression tests.

const Props = props => {
  const node = React.Children.only(props.children);
  const propEntries = Object.entries(node.props);
  return (
    <PropList>
      {propEntries
        .filter(([, value]) => typeof value !== 'function')
        .map(([key, value]) => (
          <Pill key={key} label={key} value={value} />
        ))}
    </PropList>
  );
};

This leads to visual output like this.

Screen Shot 2019-06-19 at 10 55 10 AM

Problems with this

While this was useful at the start for reviewing the initial baseline VRTs, it causes problems when we refactor our components. If you check this PR, you will see that we didn’t make any changes to the props accepted by the component. All we did was remove a surrounding HOC around the component. However, the following visual diff showed up

Screen Shot 2019-06-19 at 10 57 05 AM

Suggestion approach

Remove display of props, and use the Spec label to properly display the component state.

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:1
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
jonnybelcommented, Jun 19, 2019

I think it would be nice if we could just display the props we wanted in the VRT, instead of all of them or none of them.

For instance, on this simple Toggled example, just pass the isToggled prop (and perhaps also the isToggleButton) to make it clear which are the props that cause the visual difference.

0reactions
jonnybelcommented, Oct 9, 2020

Currently, we can either omit all props with omitPropsList and we can filter which props do display with propsToList, but most of the VRTs are still not using it.

I’m not sure if it’s worth to go through all VRTs and make them to use the filter. I guess we should try to use the filter when we refactor components and their VRT that show a diff in the props list, and also to newly added VRTs.

And would it be worth to also have a propsToHide (the opposite of propsToList)?

Read more comments on GitHub >

github_iconTop Results From Across the Web

eslint-plugin-react/jsx-props-no-spreading.md at master - GitHub
Disallow JSX prop spreading ( react/jsx-props-no-spreading )​​ Enforces that there is no spreading for any JSX attribute. This enhances readability of code by ......
Read more >
How to resolve eslint error: "prop spreading is forbidden" in a ...
ES lint discourages the use of prop spreading so that no unwanted/unintended props are being passed to the component.
Read more >
Indirect costs of a nontarget pathogen mitigate the direct ...
To assess the direct and indirect effects of plant type (VRT introgressives and non-VRT plants), year, beetle damage, and viral and wilt ...
Read more >
Genital Warts - StatPearls - NCBI Bookshelf - NIH
Physically ablative treatments are more effective at wart removal; but in many cases, topical agents are preferred by patients as initial ...
Read more >
terra.pdf
Trim a SpatRaster by removing exterior rows and/or columns that only have NAs ... the number of input geometries for each output geometry....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found