The Flow team at Facebook documents the Flow static type checker for JavaScript, with release notes, type features, and library definitions.
HN commenters mention Flow as a type-checking option for JavaScript next to TypeScript and Babel, and praise its documentation.
>Seems odd to deprecate their usage in React; why wouldn't you embrace a typically used construct in JavaScript?
Because we already did embrace it, and we found that it was a mistake.
I believe that the article addresses why mixins didn’t scale well in our React codebases. We have written a ton of React code and wanted to share our experience.
It seems quite normal to me that our experience might not match experience of other JavaScript users. React offers a component model based on functional composition solution that was not quite common in JavaScript until very recently. Paradigms are much more fundamental than languages. We found that, with React’s paradigm, in our experience, mixins were unnecessary. For sure, your mileage may vary.
>most of the issues mentioned exist everywhere with JavaScript because, well, it's a dynamic language
You might not believe me, but these issues had much less of an impact on us with React’s component model. And even less so after we started using gradual static typing with Flow (http://flowtype.org/).
>I would suspect many of the issues lie outside of using mixins and more of how everything is architected but without seeing their codebase I don't actually know that.
I have been employed by Facebook for just a few months. I have written a few relatively complex React apps myself before. I didn’t see much of a difference between the mixins I wrote previously and mixins I saw at Facebook. In my view, both mixins I wrote and mixins I saw…
No love for react-devtools [0]? I'm amazed it wasn't even an honorable mention, considering he mentioned react and redux (which is probably generally used with react).
I'm also surprised he didn't mention flowtype [1], which is by Facebook and is supported by Babel! If you're writing React, you're probably already using Babel, so using flow is very low friction.
Furthermore, if you're interested in runtime assertions, you can use babel-plugin-typecheck [2], which will convert your flowtype annotations into assertions. If we're looking to be pragmatic, IMO, this is the optimal path to take. The library that Elliot is working on looks interesting, but even he recognizes in its page that it's still a work-in-progress.
If you're writing a modern JS app and you wanna take advantage of all the ES6 goodies, you'll pick up babel. And if you're using babel, you can get jsx and flowtype for free. It's ridiculous to try and build a JS app without some sort of bundler, whether it's browserify or webpack. And if you're gonna use a bundler, pulling in a transpiler like babel is really easy and it lets you write much saner code.
Oh, and if you're already drinking the Facebook kool-aid with react, jsx, and flowtype, you'll wanna give nuclide a shot. As I understand it, it has nice flow support, with stuff like "click-to-define" and inline linting [3].
I'm using flowtype annotations with the babel plugin I mentioned above, but due to my usage of non-standard features, I can't…
I wonder how long it will take before something like this gets implemented as a `Hyperterm` [0] plugin.
I think it could be quite useful to combine `npm` packages with shell commands and `map`, `filter`, etc, in your terminal.
The only thing I am unsure about are the underlying representations of the shell output. Arrays of arrays are not very semantic, so the code that parses them would not be very pleasant.
Given a shape like:
[
[ 'PID', 'TTY', 'TIME', 'CMD' ],
[ '13750', 'pts/14', '00:00:00', 'bash' ],
[ '25193', 'pts/14', '00:00:03', 'node' ],
[ '25283', 'pts/14', '00:00:00', 'sh' ],
[ '25284', 'pts/14', '00:00:00', 'ps' ]
]
I would probably like to be able to apply some kind of transforms by default so that I can work with:
[
{ pid: '13750', tty: 'pts/14', time: '00:00:00', cmd: 'bash' },
{ pid: '25193', tty: 'pts/14', time: '00:00:03', cmd: 'node' },
{ pid: '25283', tty: 'pts/14', time: '00:00:00', cmd: 'sh' },
{ pid: '25284', tty: 'pts/14', time: '00:00:00', cmd: 'ps' }
]
Though if this was the case you would want some way of applying the right transform depending on the arguments passed into the command.
I guess the bad thing is that there is currently presumably no way of using other shell features like pipes.
Also, if you're going to start outputting different shaped data, then I think you should consider hooking this all up to `flowtype` [1] and creating type signatures to provide DX [2]
[0]…
I love JS (pretty unpopular opinion here on HN) and I love Rust also and I'm not convinced using Rust on front-end tasks would have any benefits. Yet, I strongly disagree with you on this point :
> Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint
Rust's type system is wonderful, and it's a real productivity boost. Fortunately people at Facebook developed an equivalent for JavaScript [1] because living without it would be really hard for me now.
Furthermore, Rust offers a lot of syntactic sugar that makes it feel like a really high level language (compared to C, Go or even JavaScript pre-ES6 for instance).
>it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend
It's indeed one of Rust selling point (especially for people coming from a C background) but it's not the only one. My favorite being the data-race free parallelism. I don't know the current status of multi threading in wasm, but being able to take advantage of all the cores of mobile devices could really help front-end frameworks.
[1]: http://flowtype.org, it's not inspired by Rust but inspired by OCaml, which also inspired Rust.
> What Go does better than Nodejs is a better standard library
What is so hard about `require('lodash')`, or `require('moment')`?
> true concurrency
The trade-off is you get great concurrency without thinking about it. If you are working in Go, you have to start thinking about it as you go. You can always think about it as you go with Node.js if you want, but you don't have to and you will still get quite far.
> static typing
See http://flowtype.org or http://www.typescriptlang.org. With more advanced type systems than Go.
> With Go it doesn't matter if an operation is blocking or non blocking, that fact can totally be abstracted from the client code. Writing callbacks is tedious, promises are tedious, co routines with yield need plumbing and async isn't in the spec.
You can use ES7 async/await and promises today. That it "isn't in the spec" probably won't be for too much longer.
async function() {
const {data} = axios.get('foo')
const results = []
const arr = ['foo', 'bar', 'baz']
for (const i in arr) {
results[i] = await axis.get(arr[i])
}
return results
}
Facebook still uses Flux, and it was created specifically for large applications. The thing which is missing from this example is some kind of namespacing. In a large application, you should be naming your action types in such a way that it is not confusing which application feature they relate to, eg. if you had domain logic relating to something called 'UserProfile', you might have an action like `USER_PROFILES/UPDATE_PHOTO`. Combined with sensible project layout and file naming (eg. by domain) this should make it easy to track down code relating to a particular action. It also makes for excellent 'greppability'.
If you're using a JS typechecker like Flow (and IMO if you're building a large app, you should) you can even make use of disjoint unions to type your Flux action objects: https://flowtype.org/blog/2015/07/03/Disjoint-Unions.html