5 ms·

A corollary to what I'm saying is that the design patterns that are espoused by React authors can be eliminated by using another abstraction, they're specific t

A corollary to what I'm saying is that the design patterns that are espoused by React authors can be eliminated by using another abstraction, they're specific to React and have nothing to do with programming in general. I wouldn't go so far as to say, never use mixins in JavaScript, for example. >You don’t “have to” do those optimizations. Sure, but it seems to be a trade off of complexity for user experience. It's just covering up a leaky abstraction.

jhall1468 10y ago
> they're specific to React and have nothing to do with programming in general. I can't think of a single design pattern used in React that isn't a highly common design pattern in any number of languages. HOC's are just a React implementation of Higher-order Functions. > I wouldn't go so far as to say, never use mixins in JavaScript, for example. Neither did they... This doesn’t mean that mixins themselves are bad. People successfully employ them in different languages and paradigms, including some functional languages... Nevertheless, we think that mixins are unnecessary and problematic in React codebases.
danabramov 10y ago
>they're specific to React and have nothing to do with programming in general Higher-order functions are extremely common and useful in all functional languages. In fact many people gave us the exact opposite feedback: React taught them many functional programming patterns that they later used elsewhere, both with and without JavaScript, not to say React. >I wouldn't go so far as to say, never use mixins in JavaScript, for example. This is not what the article says. There is a paragraph clarifying this specific point, as the sibling comment points out. And the article is sprinkled with “in React codebases” and “in our experience” for this very reason. >Sure, but it seems to be a trade off of complexity for user experience. I don’t understand what you mean. In most cases you don’t need to do anything, React is fast. When you have an especially complex tree (not very common), you can add three lines to a few files, and React is even faster. It is a tradeoff, and it is a pretty damn good tradeoff in my experience working on React apps. What am I missing?
- daliwali 10y ago
  >Higher-order functions are extremely common and useful in all functional languages. Yes but higher order components as you call them, seem to be an abstraction that you would only use because the base unit of organization is a React component. I'm of the opinion that design patterns emerge due to deficiencies in the language or abstraction level, and that they can be avoided.
  - danabramov 10y ago
    >Yes but higher order components as you call them, seem to be an abstraction that you would only use because the base unit of organization is a React component. I don’t really see the issue here. “How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific. The unit of organization is indeed the component. Again, I’m not sure I understand why it being a first-class thing indicates a deficiency. By this logic, functions are deficient in JavaScript because you can pass a function to [].map(), or Promises are deficient because you can resolve() a Promise to another Promise. I think the opposite is true. The abstractions are more powerful when they afford building higher level abstractions on top of them. Obviously you shouldn’t overuse this, just like you shouldn’t overuse higher order functions, but it’s a nice property to have.
    - daliwali 10y ago
      >“How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific. I'm not talking about the what, but why would anyone think of using higher order functions to build user interfaces in the first place. It complicates the use case: building and mutating DOM Nodes. >I think the opposite is true. The abstractions are more powerful when they afford building higher level abstractions on top of them. And what may I ask requires so much power for building web front-ends?
      - pka 10y ago
        Higher order functions are not such a complicated concept. Just a function passed to a function. You use functions, right?

jhall1468 10y ago

> they're specific to React and have nothing to do with programming in general. I can't think of a single design pattern used in React that isn't a highly common design pattern in any number of languages. HOC's are just a React implementation of Higher-order Functions. > I wouldn't go so far as to say, never use mixins in JavaScript, for example. Neither did they... This doesn’t mean that mixins themselves are bad. People successfully employ them in different languages and paradigms, including some functional languages... Nevertheless, we think that mixins are unnecessary and problematic in React codebases.

danabramov 10y ago

>they're specific to React and have nothing to do with programming in general Higher-order functions are extremely common and useful in all functional languages. In fact many people gave us the exact opposite feedback: React taught them many functional programming patterns that they later used elsewhere, both with and without JavaScript, not to say React. >I wouldn't go so far as to say, never use mixins in JavaScript, for example. This is not what the article says. There is a paragraph clarifying this specific point, as the sibling comment points out. And the article is sprinkled with “in React codebases” and “in our experience” for this very reason. >Sure, but it seems to be a trade off of complexity for user experience. I don’t understand what you mean. In most cases you don’t need to do anything, React is fast. When you have an especially complex tree (not very common), you can add three lines to a few files, and React is even faster. It is a tradeoff, and it is a pretty damn good tradeoff in my experience working on React apps. What am I missing?

daliwali 10y ago
>Higher-order functions are extremely common and useful in all functional languages. Yes but higher order components as you call them, seem to be an abstraction that you would only use because the base unit of organization is a React component. I'm of the opinion that design patterns emerge due to deficiencies in the language or abstraction level, and that they can be avoided.
- danabramov 10y ago
  >Yes but higher order components as you call them, seem to be an abstraction that you would only use because the base unit of organization is a React component. I don’t really see the issue here. “How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific. The unit of organization is indeed the component. Again, I’m not sure I understand why it being a first-class thing indicates a deficiency. By this logic, functions are deficient in JavaScript because you can pass a function to [].map(), or Promises are deficient because you can resolve() a Promise to another Promise. I think the opposite is true. The abstractions are more powerful when they afford building higher level abstractions on top of them. Obviously you shouldn’t overuse this, just like you shouldn’t overuse higher order functions, but it’s a nice property to have.
  - daliwali 10y ago
    >“How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific. I'm not talking about the what, but why would anyone think of using higher order functions to build user interfaces in the first place. It complicates the use case: building and mutating DOM Nodes. >I think the opposite is true. The abstractions are more powerful when they afford building higher level abstractions on top of them. And what may I ask requires so much power for building web front-ends?
    - pka 10y ago
      Higher order functions are not such a complicated concept. Just a function passed to a function. You use functions, right?