(Shameless plug)

I wrote this library react-loadable to standardize the workflow around code-splitting at the component-level and asynchronously loading components. I wrote a blog post too.

Facebook does code-splitting this way too.

I think we should be encouraging more of the community to do this since I've heard of people dropping 100s of KBs from their bundles. It's really more a pattern than a library anyways.

https://vasanthk.gitbooks.io/react-bits/patterns/32.list-components.html

I suggest putting that list item mapping function above SearchSuggestions component definition like below:

const renderSearchSuggestion = listItem => (
  <li key={listItem.id}>{listItem.name} {listItem.id}</li>
);

const SearchSuggestions = (props) => {
  return (
    <ul>
      {props.listItems.map(renderSearchSuggestion)}
    </ul>
  );
};

That way we do not create a new function each time SearchSuggestions rerenders.

In my understanding, titles of Refs over findDomNode() and HOC over mixins in anti-patterns are actually preferred patterns. These two titles looks so weird in Anti-Patterns sections.

It must be titled as findDomNode over Refs and mixins over HOC to be anti-patterns and consistent with other parts.

it would be awesome if this was made with gitbook, easey to ready/navigate... is there any possibility to make this a gitbook doc?

From reading about do expressions, it seems that the code section under the text

With an appropiate transpiler you can take advantage of the upcoming do expression which is currently on stage-1

should be do { instead of do => { on line 5, but I'm not 100% sure. Can someone please clarify?

According to Spreading props on DOM elements, it is recommended to use a domProps object to spread props on DOM elements.

GOOD

By creating props specifically for DOM attribute, we can safely spread.

const Sample = () => (<Spread flag={true} domProps={{className: "content"}}/>);
const Spread = (props) => (<div {...props.domProps}>Test</div>);

But directly passes domProps prop may cause unnecessary update in PureComponent.

Here is an example

import React, { Component, PureComponent } from 'react';
import { render } from 'react-dom';

class Spread extends PureComponent {
  componentDidUpdate() {
    console.log('updated'); // will show
  }

  render() {
    return (
      <div {...this.props.domProps}>Test</div>
    );
  }
}

class App extends Component {
  componentDidMount() {
    this.forceUpdate();
  }

  render() {
    return (
      <Spread flag={true} domProps={{ className: 'content' }}/>
    );
  }
}

render(<App />, document.getElementById('mount'));

Here is my solution by omitting unknown HTML props

import React, { Component, PureComponent } from 'react';
import { render } from 'react-dom';

class Spread extends PureComponent {
  componentDidUpdate() {
    console.log('updated'); // will NOT show
  }

  render() {
    const {
      flag, // eslint-disable-line
      ...other,
    } = this.props;
    return (
      <div {...other}>Test</div>
    );
  }
}

class App extends Component {
  componentDidMount() {
    this.forceUpdate();
  }

  render() {
    return (
      <Spread flag={true} className="content"/>
    );
  }
}

render(<App />, document.getElementById('mount'));

Another solution is caching domProps object, but I think both of my solutions are not elegant 😂

Hi! First of all wanted to say thank you for contributing such an great set of resources and information about React stuff. Awesome job!

Still haven't finished reading all of the content in the repo, but when I read the example in https://github.com/vasanthk/react-bits/blob/master/13.layout-container.jsx, I found some incorrect information regarding the optimization that can be made there.

It says:

// While HorizontalSplit will be parent to both components, it will never be their owner.
// We can tell it to update never, without interrupting the lifecycle of the components inside.

This in fact won't work as it is explained there. The reconciliation in React does not depend on the elements being owners or not. If the HorizontalSplit component doesn't render, its content won't update either, it doesn't matter if the elements were received via props or created by the component directly.

You can try that in this fiddle I created: https://jsfiddle.net/69z2wepo/74765/

I don't think there's a good way to tell React that a component is static and avoid its reconciliation. At least not a straight forward way.

Maybe that pattern should not talk about perf improvements and only about splitting layout vs content components, which is a good idea by itself anyway?

I'm starting to use a pattern like this frequently. The reason being there are multiple date-pickers in Scheduler and if you use a component instead of just another object of props you get code completion, etc. and the consuming engineer doesn't need to go look the prop up on the doc site.

Maybe it's a type of HOC pattern, because typically the Datepicker component just gets discarded by Scheduler and the props are stolen. Any naming suggestions?

"Grandfather steals from grandprops" doesn't fly off the tongue that easily. 😄

<Scheduler
  datepickerSharedProps={<Datepicker
    assistiveText={{
      openCalendar: 'Open Calendar',
      nextMonth: 'Next month',
      previousMonth: 'Previous month'
    }}
    formatter={(date) => {
      let inputText = '';
      /* Make American or the Entire Rest of the World format here. */
      if (date) {
        inputText = `${date.getMonth() + 1}/${date.getDate()}/${date.getFullYear()}`;
      }
      return inputText;
    }}
  />}
/>

Maybe Child Component Proxy?

https://github.com/enaqx/awesome-react

Thanks for the bits. 👍

I just read a few examples, but many of them look a bit too esoteric, and for instance they don't pass a "standard" linter (e.g. the classic eslint+airbnb). One for all, nesting ternary operators.

I think in general this could improve a ton if the "wrong examples" wouldn't be abstract, but concrete/real world enough, and in general not things that a linter would catch already. (Not trying to be overly critic, love this kind of works.)

Hey! Thanks for your work on creating learning material in this repo.

I think the list of “conventions” is highly subjective right now. The React team never advocated any of them, and in fact I think the team would disagree with some:

• https://github.com/vasanthk/react-bits/blob/master/conventions/02.adding-class-names.md: It's fine to use arrays if you'd like.
• https://github.com/vasanthk/react-bits/tree/master/conventions: There is nothing bad at all about using methods!
• https://github.com/vasanthk/react-bits/blob/master/conventions/05.use-html-entities.md: String.fromCharCode() is not “React’s”, and also not an “HTML entity” (that’s a different thing). And I don’t quite understand why this is recommended here (what is the difference?)
• https://github.com/vasanthk/react-bits/blob/master/conventions/08.closures-in-render.md: It won’t matter in many cases, and the advice doesn’t really explain how to bind methods.
• https://github.com/vasanthk/react-bits/blob/master/conventions/09.functional-components.md: I would not recommend to rely on hoisting because it is confusing.
• https://github.com/vasanthk/react-bits/blob/master/conventions/10.formatting-props.md: This is just a style opinion.
• https://github.com/vasanthk/react-bits/blob/master/conventions/11.super-in-constructor.md: We actually recommend using super(props) if you define constructor because somebody reading that code later might be surprised that this.props doesn’t work.

It would be great to separate author’s stylistic preferences from correctness advice (e.g. about tbody) and clearly label it as such. Those are not React community’s conventions, nor are they recommended by React team.

Its fantastic list so far, i have being following it very closely. However, recently i have being struck with role-based implementation in react. Any thoughts on this you came across?

This is a dupe of #21.

The issue is not resolved. The delay was on account of my father passing away. Obviously this is a decidedly less important issue. However, I will do my best to file the appropriate paperwork this week.

This issue of plagiarism for this repo and all forks remains an open issue.

Hey,

I feel we should add more clarity on the anti pattern bits.
For instance, in the refs over findDOMNode(), in the code comments, it's saying: Use findDOMNode() over callback refs which is kind of stating you should use findDOMNode over refs, although after reading the references, it's clearly the opposite we should do.

Although on the HOC over Mixins example (and that's where I think there is some confusion), it's saying Use Higher order components over Mixins, which this time is the right approach.

How do you feel about choosing one or the other approach but staying consistent? I'd suggest saying something like Use "this" over "that" kind of structure.

Based on the description. If project owners are ok enable Stage 2 Babel transformation it is a good alternative to bind in the constructor.

class Switcher extends React.Component {
  constructor(props) {
    super(props);
    this.state = { name: 'React in patterns' };
  }
  render() {
    return (
      <button onClick={ this.onButtonClick }>
        click me
      </button>
    );
  }
  onButtonClick = () => {
    console.log(`Button is clicked inside ${ this.state.name }`);
  }
}

Let me know if you accept the PR.

as title suggest , we should consider to update readme file links as latest PR changes

facebook/react#2127

Thank you.

Most of the code are not runnable. Instead of using JSX, please use markdown for easier reading.

In Section Conditional Rendering, It says:

You can’t use regular if/else conditions inside a component definition. The conditional (ternary) operator is your friend.

I think it is wrong. Because instead of

// if- else (big blocks)
function render() {
  return condition ? (
    <span>
    Rendered when `truthy`
  </span>
  ) : (
    <span>
    Rendered when `falsey`
  </span>
  )
}

this render function can also be written in a if/else way:

function render() {
  if (condition) {
    return  (
      <span>
        Rendered when `truthy`
      </span>
    )
  }
  else {
    return  (
      <span>
        Rendered when `falsey`
      </span>
    )
  }
}

I think there's enough interest in Typescript to maybe copy this over and redo in TS and TSX files.

When I click on the link https://vasanthk.gitbooks.io/react-bits/content/ I expect to be taken to the content. Instead, I get a 401 Unauthorized error.

i'm too lazy to PR

Here is my tips

modify the tagname according to the parameter

    const Wrap = ({ tagName, content }) => { 
      const Tag = `${tagName}`     // variable name must begin with capital letters
      return <Tag>{content}</Tag>
    }

Anti-patterns' Using Indexes as key section is based on an outdated article and is no longer correct.

Keys should be stable, predictable, and unique. Unstable keys (like those produced by Math.random()) will cause many component instances and DOM nodes to be unnecessarily recreated, which can cause performance degradation and lost state in child components.

• React docs

A more entertaining explanation can be found here (credit to Lin Clark).

Suggestions:

• replace the blog link with a link to the React docs
• remove the "Even Better" section
• rename the "Better" section title to "Good"
• add an explanation how obj.id should be unique and repeatable among all siblings

@vasanthk I'm happy to open a PR for this, if you are satisfied with the suggestions I made 👍

Many of the items are plagiarised from reactpatterns.com, which is not licensed.

The content on reactpatterns.com is not licensed. Making this content a copyright violation.

Please let me know that you received this issue and we'll work toward an immicable solution.

As a trainer I take these violations very seriously.

In Dependency Injection section, link to the page DI in React isn't working. Can someone please fix?

Iam confused now. Here examples spread props on dom div:
https://github.com/vasanthk/react-bits/blob/master/patterns/02.jsx-spread-attributes.md

However, looking at the anti pattern list, the above is not recommended:
https://github.com/vasanthk/react-bits/blob/master/anti-patterns/07.spreading-props-dom.md
If spread on dom elements is not recommended, all examples should be modified to use recommended pattern.

Cheers
Leonardo

Given this: https://github.com/vasanthk/react-bits/blob/master/patterns/18.conditionals-in-jsx.md
What about something like this:

const sampleComponent = () => {
  const basicCondition = flag && flag2 && !flag3;
  const obj = {
    'flag4': 'Blah',
    'flag5: 'Meh'
  };
  if (basicCondition) {
    return <p>{obj[flagName] || Herp}</p>
  }
  return <p>Derp</p>
};