6 ms·

Hey, author here :) I am curious about your experiences using/learning React. Are there any other JavaScript topics which are important when starting out with R

• rsyring 8y ago
  May want to point out you are the author of the article. :)
  • rwieruch 8y ago
    Done :)
• kansface 8y ago
  Formatting strings (template literals [1]) comes up frequently for constructing ids/refs/various other props. 1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  • rwieruch 8y ago
    Included :)
• vga805 8y ago
  hey there, nice write-up two minor things that you might include are 1: rest in the context of function args 2: short circuiting: e.g. `isLoading && <Loading />`
  • rwieruch 8y ago
    Included. Thanks :)
• k__ 8y ago
  Nice writeup! I wrote a tutorial that would be the next step to yours, called React From Zero[0] I try to teach React here with the basic JavaScript knowledge most people already have. [0] https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero
  • scns 8y ago
    I can recommend this, having only read the first two, very enlightening. Thank you for your work.
• hoorayimhelping 8y ago
  This is great! Great write up and good idea on what to actually write about. One suggestion I'd make is to use ES6 template literals over concatenation, since you're using other ES6 constructs anyway. getName() { return `${this.firstname} ${this.lastname}`; } Cleaner and less error prone. On our team we had a convention to only use backticks when we intended to combine strings, so that if you ever saw a backtick, you knew a string was being built, likely for output.
  • rwieruch 8y ago
    Included it :)
• sorahn 8y ago
  It’s worth noting that using the fat arrow syntax for class functions make them exponentially harder to unit test because they do not exist on the Prototype of the component, but are instead only initialized when the class is initialized. If you are trying to unit test a function that calls another function in the same class you cannot mock the second one it if it is a fat arrow.
  • dvlsg 8y ago
    I feel like testing things by replacing pieces of a prototype would be fairly fragile anyways. Is there a reason you couldn't use some form of composition to mock / abstract your dependencies instead?
    • sorahn 8y ago
      Given this super contrived example: https://gist.github.com/sorahn/2b287c2a97a12e318585e84d9a9e837e https://gist.github.com/sorahn/2b287c2a97a12e318585e84d9a9e8... If 'baz' was a fat arrow function, you would never be able to test bar in isolation. for example: Jest is set up so it's super easy to say `jest.spy(Foo.prototype, 'baz').mockReturnValue('whatever')`and test that bar is doing the right thing.
      • Touche 8y ago
        Mocking should only be used for extreme circumstances. This class is very easy to test without mocking. `bar` takes no arguments and has no external dependencies and therefore should always return the same result.
        • sorahn 8y ago
          OK, you caught me, give bar an argument. (I'll edit the gist) Why should mocking only be used in 'extreme circumstances'? I want to test what bar does, and I don't care what baz does, and if someone breaks baz, my unit tests for bar shouldn't fail, because it is doing its job. I would mock it if it was calling some function in another module, so what's the difference if it's calling another function in the class?
• cygned 8y ago
  I think, the most important aspect I tell my developers is to not define functions inline during render. So, do not do this: <button onClick={ () => this.smth() }></button> This creates a new function every time the rendering happens and mutates the prop onClick on every render. Once you have a component with a lot of elements (e.g. inputs) and child components that check for changes props to determine whether to render, this will get you in performance trouble. We do not use class arrow functions but instead have helpers to bind specific functions to the component's context or generate setter functions.
  • wongma 8y ago
    I usually do this when I need to pass arguements in: <button onClick={ (arg) => this.smth(arg) }></button> How can I do this without defining a function?
    • tills13 8y ago
      isn't that functionally equivalent to `onClick={ this.smth }`?
      • barskern 8y ago
        No it is not equal because the former autobinds `this` into the body of the arrow function, however the latter is "just" a function pointer hence will not be called with the correct `this` value. One way to get around this is using `this.smth.bind(this)`, which binds the correct `this` for the later execution.
      • wongma 8y ago
        no, because you're not passing the arg in now right?
        • williamdclt 8y ago
          Of course you are. The `smth` method will receive whatever arguments the caller gives. This totally works but only if `smth` has been declared as an arrow function (so that is captures the class `this` context).
• michael_michael 8y ago
  I am learning React and ES6 currently. I dove into React before really understanding ES6, and your article is really helping to illuminate some of the dark corners of JS. Thank you. One section I was hoping would get more treatment in your article (like the same treatment you gave classes, which was great) was imports/exports. Named vs. default exports are kind of baffling for a newcomer, and the usage of the named import with curly bracket syntax seems completely arbitrary. I am sure there are many, many good explanations of named vs. default imports/exports out there on the Internet, but this is one that leaped out at me. I was a little disappointed that the section on imports/exports was so comparatively short. It mostly discussed the usage of imports/exports in CRA. Still, awesome article. Thanks again.
  • rwieruch 8y ago
    Extended the section about imports and exports. Thanks for your feedback!