5 ms·

> How do I know if a function does a network call? Saves a file? It returns Promise<T> > Changes the DOM? It doesn't. React does that. ;) Basically, TypeScr

by spion 10y ago

> How do I know if a function does a network call? Saves a file? It returns Promise<T> > Changes the DOM? It doesn't. React does that. ;) Basically, TypeScript + React + a mostly purely functional style with a sprinkle of side-effecting IO is a really, really good combination. Also, I find the argument a bit silly. "This cycling helmet doesn't protect your knees and elbows and spine, so its completely useless and you can remove it!"

leshow 10y ago
React is not "functional". You extend the Component type just to make a view, you can encapsulate local state, you can inherit functions, yadda yadda. Calling it a "component" doesnt make it any less OO
- spion 10y ago
  In terms of DOM manipulation, yes it is. The render function is pure.
  - leshow 10y ago
    No, you can choose to write it purely, but it's not pure by default. You can see that here: https://facebook.github.io/react/docs/pure-render-mixin.html https://facebook.github.io/react/docs/pure-render-mixin.html "IF your React component's render function is "pure"" nothing stops you from writing impure rendering functions. You can delete and manipulate elements at will.
    - spion 10y ago
      Yes, but thats not how the render function is supposed to work. Its a function from state/props to a VDOM tree. In contrast, direct DOM manipulation is meant to be stateful. For some reason, everyone always likes dealing with absolutes. Thats not how things work * "Tests wont exhaustively check everything!" Yes but they exercise the common cases, and the cases where the code will trip-up in real use are rare if the code is decently covered with tests. Yes, its still possible to encounter edge cases. If it looks like that might be the case, add fuzz testing and property testing too. Pick the tool. * "Types wont detect all errors!" - Yes but detecting some errors is still useful. They mostly track dependencies between parts of the codebase: they determine how modules talk to eachother. This is useful, especially when I'm reorganizing code. Also, its exactly where unit test fail to help, due to mocks: if I change module M, i don't know whether its dependencies are affected or not without looking at all of them and checking their mocks of module M. The situation gets even worse for second-level dependencies, and so on. * "Unsound type systems are useless!" - No they are not. Not if its possible to isolate unsound usage and "hand-prove" it by carefully checking it. There is still value there: you can write things that the type system doesn't know are sound and hand-check them (by paying with more effort), or you can write things that it does know are sound, and enjoy the type system's ability to help you avoid errors. * "Soundness isn't very important" - It depends. Is this unsoundness pervasive, like the null/undefined unsoundness? Maybe its useful to fix it then. There are no absolutes.
      - leshow 10y ago
        > Yes, but thats not how the render function is supposed to work. If you weren't supposed to do it they wouldn't give you functions to do it. I'm not 'dealing in absolutes' I'm applying the definition of pure to what React is, and it isn't pure. The rest of your post I don't follow, you're just talking to yourself, I haven't made any of these claims.
        spion 10y ago
        Yeah I suppose I am talking to myself. I'll try to stay on topic. With the browser DOM model, end-users perform the DOM mutations. This generally means that they must keep the application state in sync with the DOM state, manually. React's VDOM model encourages pure render functions, since a new VDOM is constructed every time and mutations are performed by React itself. Also, nothing stops you from writing impure functions in PureScript either. You could define FFI functions that claim to be pure but aren't. I guess PureScript isn't pure then? Oh, and Haskell isn't pure due to unsafePerformIO. So nothing is absolutely pure; the question is what style is generally encouraged by the design of the framework/language, and to what degree. (there are no absolutes) And PureRenderMixin isn't default because it does a shallow reference comparison on props/state, which only works reliably for immutable data structures. If all JS datastructures were immutable, it would've been used everywhere. However thats unrelated to whether `render` is pure.
- qwertyuiop924 10y ago
  Well, yes, but it's commonly written in the functional style.
jeremiep 10y ago
> It returns Promise<T> That still doesn't say anything; is the action referentially transparent? is that a delay? a network call? All a Promise tells me is that the result will come at a later point in time. > It doesn't. React does that. ;) My point was about side-effects and complexity in general which the static type-system is generally very clueless about. React is a runtime and dynamic solution to that problem; types aren't really useful here :) Besides, you're most likely using React with Immutable.js and having some pattern like Redux on top. Which is basically choosing immutability and hostility to state over static types :) > "This cycling helmet doesn't protect your knees and elbows and spine, so its completely useless and you can remove it!" That's not what I meant, its more like "why wear winter clothes in the summer?"
- Too 10y ago
  Because winter is coming. It's easy to read code you wrote yourself 5 minutes ago, try again in 6 months.
  - jeremiep 10y ago
    Simplicity will help me understand my code 6 months down the road; everything else is superficial and noise in comparison. You can't hold more than ~7 things at once in your head; once things are that simple you can see bugs a mile away, types or not. The inverse is not true; types won't help you juggle 15 things at once and bugs will happily slide through the cracks. You're going to forget your codebase, types or not, and when you come back to it only simplicity will help you quickly figure out what you were doing with it.
    - spion 10y ago
      I used to think like this, and I was wrong. As you add code to a software project, some of this code will be written when the problem is not well understood; thats inevitable. The solution will then need to be refactored or rewritten, the first of which is extremely painful in a dynamic language, even if you keep things simple. For example: if you implement a store that only sells electronic books will have a lot of assumptions regarding the selling and delivery process. Later the business wants to start selling physical things and needs to handle stuff like shipping costs, tracking and so on. For problems like online stores, the possible directions in which they can develop are well understood and its easier to plan ahead. For most other things, its not, and the ability to reorganise code to be usable in different ways is invaluable.

by spion 10y ago

leshow 10y ago

React is not "functional". You extend the Component type just to make a view, you can encapsulate local state, you can inherit functions, yadda yadda. Calling it a "component" doesnt make it any less OO

spion 10y ago
In terms of DOM manipulation, yes it is. The render function is pure.
- leshow 10y ago
  No, you can choose to write it purely, but it's not pure by default. You can see that here: https://facebook.github.io/react/docs/pure-render-mixin.html https://facebook.github.io/react/docs/pure-render-mixin.html "IF your React component's render function is "pure"" nothing stops you from writing impure rendering functions. You can delete and manipulate elements at will.
  - spion 10y ago
    Yes, but thats not how the render function is supposed to work. Its a function from state/props to a VDOM tree. In contrast, direct DOM manipulation is meant to be stateful. For some reason, everyone always likes dealing with absolutes. Thats not how things work * "Tests wont exhaustively check everything!" Yes but they exercise the common cases, and the cases where the code will trip-up in real use are rare if the code is decently covered with tests. Yes, its still possible to encounter edge cases. If it looks like that might be the case, add fuzz testing and property testing too. Pick the tool. * "Types wont detect all errors!" - Yes but detecting some errors is still useful. They mostly track dependencies between parts of the codebase: they determine how modules talk to eachother. This is useful, especially when I'm reorganizing code. Also, its exactly where unit test fail to help, due to mocks: if I change module M, i don't know whether its dependencies are affected or not without looking at all of them and checking their mocks of module M. The situation gets even worse for second-level dependencies, and so on. * "Unsound type systems are useless!" - No they are not. Not if its possible to isolate unsound usage and "hand-prove" it by carefully checking it. There is still value there: you can write things that the type system doesn't know are sound and hand-check them (by paying with more effort), or you can write things that it does know are sound, and enjoy the type system's ability to help you avoid errors. * "Soundness isn't very important" - It depends. Is this unsoundness pervasive, like the null/undefined unsoundness? Maybe its useful to fix it then. There are no absolutes.
    - leshow 10y ago
      > Yes, but thats not how the render function is supposed to work. If you weren't supposed to do it they wouldn't give you functions to do it. I'm not 'dealing in absolutes' I'm applying the definition of pure to what React is, and it isn't pure. The rest of your post I don't follow, you're just talking to yourself, I haven't made any of these claims.
      - spion 10y ago
        Yeah I suppose I am talking to myself. I'll try to stay on topic. With the browser DOM model, end-users perform the DOM mutations. This generally means that they must keep the application state in sync with the DOM state, manually. React's VDOM model encourages pure render functions, since a new VDOM is constructed every time and mutations are performed by React itself. Also, nothing stops you from writing impure functions in PureScript either. You could define FFI functions that claim to be pure but aren't. I guess PureScript isn't pure then? Oh, and Haskell isn't pure due to unsafePerformIO. So nothing is absolutely pure; the question is what style is generally encouraged by the design of the framework/language, and to what degree. (there are no absolutes) And PureRenderMixin isn't default because it does a shallow reference comparison on props/state, which only works reliably for immutable data structures. If all JS datastructures were immutable, it would've been used everywhere. However thats unrelated to whether `render` is pure.
qwertyuiop924 10y ago
Well, yes, but it's commonly written in the functional style.

jeremiep 10y ago

> It returns Promise<T> That still doesn't say anything; is the action referentially transparent? is that a delay? a network call? All a Promise tells me is that the result will come at a later point in time. > It doesn't. React does that. ;) My point was about side-effects and complexity in general which the static type-system is generally very clueless about. React is a runtime and dynamic solution to that problem; types aren't really useful here :) Besides, you're most likely using React with Immutable.js and having some pattern like Redux on top. Which is basically choosing immutability and hostility to state over static types :) > "This cycling helmet doesn't protect your knees and elbows and spine, so its completely useless and you can remove it!" That's not what I meant, its more like "why wear winter clothes in the summer?"

Too 10y ago
Because winter is coming. It's easy to read code you wrote yourself 5 minutes ago, try again in 6 months.
- jeremiep 10y ago
  Simplicity will help me understand my code 6 months down the road; everything else is superficial and noise in comparison. You can't hold more than ~7 things at once in your head; once things are that simple you can see bugs a mile away, types or not. The inverse is not true; types won't help you juggle 15 things at once and bugs will happily slide through the cracks. You're going to forget your codebase, types or not, and when you come back to it only simplicity will help you quickly figure out what you were doing with it.
  - spion 10y ago
    I used to think like this, and I was wrong. As you add code to a software project, some of this code will be written when the problem is not well understood; thats inevitable. The solution will then need to be refactored or rewritten, the first of which is extremely painful in a dynamic language, even if you keep things simple. For example: if you implement a store that only sells electronic books will have a lot of assumptions regarding the selling and delivery process. Later the business wants to start selling physical things and needs to handle stuff like shipping costs, tracking and so on. For problems like online stores, the possible directions in which they can develop are well understood and its easier to plan ahead. For most other things, its not, and the ability to reorganise code to be usable in different ways is invaluable.