970 Matching Annotations
  1. Aug 2019
  2. Jul 2019
  3. May 2019
  4. Apr 2019
  5. Mar 2019
    1. React doesn’t need error boundaries to recover from errors in event handlers. Unlike the render method and lifecycle methods, the event handlers don’t happen during rendering. So if they throw, React still knows what to display on the screen.

      key point. since event handlers are async by nature, they are on a different 'job' (in the browser queue) and therefore even if crashing - the render cycle is not touched.

    2. Since an uncontrolled component keeps the source of truth in the DOM, it is sometimes easier to integrate React and non-React code when using uncontrolled components.

      a good example for justification to use uncontrolled components

    3. Two elements of different types will produce different trees. The developer can hint at which child elements may be stable across different renders with a key prop.

      key point: this is the algorithm React uses to detect changes

    4. React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a “virtual DOM”, but it works the same way on React Native.

      This is another definition/description for virtual DOM

    5. Note that a HOC doesn’t modify the input component, nor does it use inheritance to copy its behavior. Rather, a HOC composes the original component by wrapping it in a container component. A HOC is a pure function with zero side-effects.

      key point

    6. accessing their DOM nodes may be unavoidable for managing focus, selection, or animations.

      to make a long story short - consider a FancyButton component that actually wraps a native button element. Sometimes, the internal element - button - needs to be accessed from a client of FancyButton (such as to manage focus etc). This feature allows this. Handle with care - encapsulation is good and desired. Don't break it without careful thought!

    7. Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult. If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.

      key point

    8. Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language

      key point

    9. The dynamic import() syntax is a ECMAScript (JavaScript) proposal not currently part of the language standard. It is expected to be accepted in the near future.

      this mean, folks, that if you need to support IE - forget about import()... :-(

    10. If you can’t find a component where it makes sense to own the state, create a new component simply for holding the state and add it somewhere in the hierarchy above the common owner component.

      see also dumb/smart components (it has another name for this)

    11. Simply ask three questions about each piece of data: Is it passed in from a parent via props? If so, it probably isn’t state. Does it remain unchanged over time? If so, it probably isn’t state. Can you compute it based on any other state or props in your component? If so, it isn’t state.

      determining if the data should be 'state' or not

    12. A good rule of thumb is that elements inside the map() call need keys.

      key point. see above that the key is needed in the immediate child level in the array.map() usage, not its own child within... (see just above...)

    13. When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort: const todoItems = todos.map((todo, index) =>

      the 'index' is a part of map() function

    14. Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity:

      meaning, the key should be given to the element being iterated over

    15. In JavaScript, class methods are not bound by default

      key point and i highly recommend those not familiar with what 'this' is in JS and how it is determined to have a quick visit on guide on the internet. I recommend an online course, which is very good IMHO, but its a paid one (and covers much more than 'this' explanation)

    16. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter: // Wrong this.setState({ counter: this.state.counter + this.props.increment, }); To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument: // Correct this.setState((state, props) => ({ counter: state.counter + props.increment }));

      key point!

    17. By default, React DOM escapes any values embedded in JSX before rendering them. Thus it ensures that you can never inject anything that’s not explicitly written in your application. Everything is converted to a string before being rendered. This helps prevent XSS (cross-site-scripting) attacks.

      key point on security concerns

    18. We split JSX over multiple lines for readability. While it isn’t required, when doing this, we also recommend wrapping it in parentheses to avoid the pitfalls of automatic semicolon insertion.

      key point.

    19. Most React developers use a special syntax called “JSX” which makes these structures easier to write. The <div /> syntax is transformed at build time to React.createElement('div')

      This is a key point. Its not mandatory to use JSX. One can use React.createElement() instead...

    1. You can also add other assets to the public folder. Note that we normally encourage you to import assets in JavaScript files instead. For example, see the sections on adding a stylesheet and adding images and fonts. This mechanism provides a number of benefits: Scripts and stylesheets get minified and bundled together to avoid extra network requests. Missing files cause compilation errors instead of 404 errors for your users. Result filenames include content hashes so you don’t need to worry about browsers caching their old versions.

      great summary of why the import() in JS is better than manually handling all those

  6. Jan 2019
  7. Dec 2018
  8. Nov 2018
  9. Oct 2018
  10. Sep 2018
  11. Sep 2017
  12. Jun 2017
    1. HMR allows patching the browser state without a full refresh making it particularly handy with libraries like React where a refresh blows away the application state. The Hot Module Replacement appendix covers the feature in detail.

      Why you should prefer hot module replacement in a React development context: a full refresh, the kind your standard webpack-dev-server defaults to, will obliterate application state in React!

  13. May 2017
    1. <Route path="/" component={ List } /> <Route path="/react" component={ Detail } />

      Note, in newer versions of the router, this won't work because a route can only contain one child. Try wrapping the two routes in a <switch>:</switch>

        <Switch>
          <Route exact path="/" component={ List } />
          <Route path="/react" component={Detail}  />
        </Switch>
      
    1. <Router> <Route path="/" component={ Detail } /> </Router>,

      In newer versions of React, this won't work without a history prop and hashHistory. Depending on how you import hashHistory, the code will look something like this:

      let hashHistory = createHashHistory();
      
      <Router history={hashHistory}>
          <Route path="/" component={ Detail } />
      </Router>,
      
  14. Dec 2016
  15. Apr 2016
  16. Mar 2016
  17. Feb 2016
  18. Jan 2016
    1. Useful set of benchmarks based on the DBMonster demo for a set of different frameworks - looking at various axes such as GC collection, layout and paint times.

      There are some notable caveats in the comments though that the subjective feel was not always reflected in the metrics, suggesting that the authors believe they have not found the optimal set of metrics that reflect user-perceived performance.

  19. Dec 2015
    1. This is an interesting opinion piece on the difficulties that newcomers have with the React ecosystem and the problems with the lack of a central guidelines about which pieces to use and how to tie them altogether.

      I don't think it applies to just React though - choices around testing frameworks, build tools, languages etc. apply regardless of which framework you are using.

  20. Nov 2015
  21. Oct 2015
    1. JSX is Not an HTML Template LanguageThough it looks like it, JSX isn’t a template in the sense that Handlebars and EJS are templates. It’s not a simple token replace and `.innerHTML= foo` dump like so many other tools.

      This is a great explanation of why JSX is not a templating engine, which it is often mistaken for.

  22. Sep 2015
    1. The orderBy filter can also take a second $scope variable as parameter. In this example that variable is named reverse. The value of this variable determines if the data objects are to be sorted in their natural order, or the reverse order of that. In this case the reverse variable is set to true, meaning the data objects will be sorted in reverse order.

      Again, cf. React where one would just use a chain of map() calls.

  23. Aug 2015
    1. We’ve seen some annoying bugs as a result of events being fired twice, or in a circular event chain.

      Update loops are one of the problems that React explicitly aims to solve and Flux explicitly disallows actions triggering other actions to avoid this.