5 ms·

Hey @acemarke, thanks for the comment! For myself, I still have not decided whether I like JSX or not :) My colleague finds it great, and I like the declarativ

Hey @acemarke, thanks for the comment! For myself, I still have not decided whether I like JSX or not :) My colleague finds it great, and I like the declarative nature of it, just need to persuade myself to accept it mixed in JS file. Yes on .bind, but I got used to not having to care about it in Aurelia (and Angular also). Got my fair share of `this` handling in pre-ES6. And of course, thank you for the links. Bookmarked! :)

jmschlmrs 9y ago
Are you using arrow functions? I find that using es2015 arrow functions for class methods takes care of most of the problems around this and react. The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there. I don't use .bind() anywhere in my react code.
- miroslavpopovic 9y ago
  Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. In fact, I believe class property syntax helps with that, but we only figured it out after we built these few pages and components necessary for the web app part.
  - coldtea 9y ago
    >Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. They do. Just do: myHandler = (v) => { ... } and you don't need to bind in the constructor anymore. You'll need to use Babel of course to transpile that.
    - miroslavpopovic 9y ago
      Yes, class properties syntax. I mentioned that in the article.
      - coldtea 9y ago
        Hmm, so why do you say "but they don't help with event handlers"? Because it's not yet standard?
        miroslavpopovic 9y ago
        Sorry, I didn't think about the arrow functions being used in class property syntax too. :) So yes, they do help with event handlers, I stand corrected.
- nbclark 9y ago
  One note: From what I've read, using arrow functions as props in a render method of a component will create new functions each render, so you might end up with a good bit more GC than normal. There are some nice little mix-ins that will autobind to remove the need to remember to .bind everything.
  - miroslavpopovic 9y ago
    Not using arrow functions in JSX code to define error handler. Yes, I believe you are right, that would create multiple handlers.
  - Androider 9y ago
    Nowadays you can just stick a class property anywhere in your React component: handleSomething = (params) => { ... }; and the use it in your render function like this without any binding: <Foo onSomething={this.handleSomething}/>
    - nbclark 9y ago
      Good suggestion - Thank you
    - miroslavpopovic 9y ago
      Yes, class properties are the way to go.
solidr53 9y ago
Try react-native, react-gl or something with different render target than the web platform. It makes perfect sense to you then. The SGML syntax is just perfect for composing and nesting components. So does HTML, XML etc. You just have to get your head around the idea that you´r writing HTML, because your´re not.
ng12 9y ago
> just need to persuade myself to accept it mixed in JS file Why is this a bad thing? The most important thing about JSX is that it's a single source of truth -- you never have to wonder if data is processed in the JS or in the template. I really think everything in one file is the ideal, we've even started moving the styles inline via styled-components.
- miroslavpopovic 9y ago
  Not a bad thing. Just a personal preference of trying to separate views and view models for a long time. I believe it just needs some time to get used to it. As I said, I really do like declarative nature of JSX, knowing that it's just compiled to a regular JS/DOM code.
  - foota 9y ago
    Fwiw I think "compiled to" is a bit of a misnomer. From my understanding it's more like a DSL that gets interpreted by the renderer.
    - ng12 9y ago
      I think compilation is fair wording -- JSX is just sugar around the createElement API. : https://facebook.github.io/react/docs/react-api.html#createelement https://facebook.github.io/react/docs/react-api.html#createe...
      - foota 9y ago
        A bit late, but my thought is that compiled to js/Dom api to me implies that it's compiled directly to document.createElement and friends.
antihero 9y ago
I've found that the best way to make event handlers is instead of doing class Blah { private handleThing(...) {} } to instead do this class Blah { private handlething = (...) => {} } this means that it is created only once, at instantiation of the component, so it is fast, looks decent, and has access to `this` as it's technically a method on the object, not the class. Also, if you're coming from C# land, head straight to TypeScript 2.3 - it's lush and handles the latest ECMAScript stuff wonderfully, and you get static type checking, interfaces, union types, etcetera. The only issue is when a package has no type definitions or no supplementary @types package, which sucks but they exist for most popular packages. Also VS Code is built with it in mind and brilliant to work with. As for stacks, I'm currently really enjoying redux/redux-observable and my helper lib redux-rx-http (for API), I find harnessing the power of RxJS to manage side-effects through "epics" is a really elegant and decoupled way to chain a bunch of things that you want happen together.
- miroslavpopovic 9y ago
  Yep, the class property syntax helps with event handlers. As for C# and TypeScript, we also have a very strong JavaScript background, from vanilla pre-ES6 to the latest ES2017+. We still prefer JavaScript to TypeScript, although out of languages that compile to JS, TypeScript is the best in our opinion.
- jbrantly 9y ago
  One problem with using fat arrow syntax like this is the method is no longer attached to the prototype so it's not shared across all instances and is less memory efficient. It also doesn't work well with React HMR if you're using that. If you can use decorators I highly recommend autobind-decorator: https://github.com/andreypopp/autobind-decorator https://github.com/andreypopp/autobind-decorator Also I think you're using a TypeScript-specific `private` syntax there which likely changes the runtime semantics so my comment really only applies if you don't use that.

jmschlmrs 9y ago

Are you using arrow functions? I find that using es2015 arrow functions for class methods takes care of most of the problems around this and react. The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there. I don't use .bind() anywhere in my react code.

miroslavpopovic 9y ago
Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. In fact, I believe class property syntax helps with that, but we only figured it out after we built these few pages and components necessary for the web app part.
- coldtea 9y ago
  >Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. They do. Just do: myHandler = (v) => { ... } and you don't need to bind in the constructor anymore. You'll need to use Babel of course to transpile that.
  - miroslavpopovic 9y ago
    Yes, class properties syntax. I mentioned that in the article.
    - coldtea 9y ago
      Hmm, so why do you say "but they don't help with event handlers"? Because it's not yet standard?
      - miroslavpopovic 9y ago
        Sorry, I didn't think about the arrow functions being used in class property syntax too. :) So yes, they do help with event handlers, I stand corrected.
nbclark 9y ago
One note: From what I've read, using arrow functions as props in a render method of a component will create new functions each render, so you might end up with a good bit more GC than normal. There are some nice little mix-ins that will autobind to remove the need to remember to .bind everything.
- miroslavpopovic 9y ago
  Not using arrow functions in JSX code to define error handler. Yes, I believe you are right, that would create multiple handlers.
- Androider 9y ago
  Nowadays you can just stick a class property anywhere in your React component: handleSomething = (params) => { ... }; and the use it in your render function like this without any binding: <Foo onSomething={this.handleSomething}/>
  - nbclark 9y ago
    Good suggestion - Thank you
  - miroslavpopovic 9y ago
    Yes, class properties are the way to go.

solidr53 9y ago

Try react-native, react-gl or something with different render target than the web platform. It makes perfect sense to you then. The SGML syntax is just perfect for composing and nesting components. So does HTML, XML etc. You just have to get your head around the idea that you´r writing HTML, because your´re not.

ng12 9y ago

> just need to persuade myself to accept it mixed in JS file Why is this a bad thing? The most important thing about JSX is that it's a single source of truth -- you never have to wonder if data is processed in the JS or in the template. I really think everything in one file is the ideal, we've even started moving the styles inline via styled-components.

miroslavpopovic 9y ago
Not a bad thing. Just a personal preference of trying to separate views and view models for a long time. I believe it just needs some time to get used to it. As I said, I really do like declarative nature of JSX, knowing that it's just compiled to a regular JS/DOM code.
- foota 9y ago
  Fwiw I think "compiled to" is a bit of a misnomer. From my understanding it's more like a DSL that gets interpreted by the renderer.
  - ng12 9y ago
    I think compilation is fair wording -- JSX is just sugar around the createElement API. : https://facebook.github.io/react/docs/react-api.html#createelement https://facebook.github.io/react/docs/react-api.html#createe...
    - foota 9y ago
      A bit late, but my thought is that compiled to js/Dom api to me implies that it's compiled directly to document.createElement and friends.

antihero 9y ago

I've found that the best way to make event handlers is instead of doing class Blah { private handleThing(...) {} } to instead do this class Blah { private handlething = (...) => {} } this means that it is created only once, at instantiation of the component, so it is fast, looks decent, and has access to `this` as it's technically a method on the object, not the class. Also, if you're coming from C# land, head straight to TypeScript 2.3 - it's lush and handles the latest ECMAScript stuff wonderfully, and you get static type checking, interfaces, union types, etcetera. The only issue is when a package has no type definitions or no supplementary @types package, which sucks but they exist for most popular packages. Also VS Code is built with it in mind and brilliant to work with. As for stacks, I'm currently really enjoying redux/redux-observable and my helper lib redux-rx-http (for API), I find harnessing the power of RxJS to manage side-effects through "epics" is a really elegant and decoupled way to chain a bunch of things that you want happen together.

miroslavpopovic 9y ago
Yep, the class property syntax helps with event handlers. As for C# and TypeScript, we also have a very strong JavaScript background, from vanilla pre-ES6 to the latest ES2017+. We still prefer JavaScript to TypeScript, although out of languages that compile to JS, TypeScript is the best in our opinion.
jbrantly 9y ago
One problem with using fat arrow syntax like this is the method is no longer attached to the prototype so it's not shared across all instances and is less memory efficient. It also doesn't work well with React HMR if you're using that. If you can use decorators I highly recommend autobind-decorator: https://github.com/andreypopp/autobind-decorator https://github.com/andreypopp/autobind-decorator Also I think you're using a TypeScript-specific `private` syntax there which likely changes the runtime semantics so my comment really only applies if you don't use that.