Flow type checker from Facebook is nice and all, but dead. Long story short, Nuclide died, Atom is dying, Flow is dying too. VSCode can be beautiful and minimal, etc. So, how to migrate of?

1. Use https://github.com/flowtype/flow-remove-types to remove Flow stuff from your code.
2. Rename .js files to .tsx
3. …
4. Profit!

OK, it’s not so easy but isn’t hard neither. Check este-typescript for tips.

Or hire me. https://javascript-skoleni.com or daniel@steigerwald.cz

As graphql.org says, evolve your API without versions.

I don’t know how “@deprecated” directive works (TODO: Investigate it). But I know stale not yet updated app can fetch from new updated GraphQL API when API is updated but an app not. Then what? Relay compiler generates Flow types based on GraphQL schema, and leverages GraphQL non-nullable, so app will not crash, instead it will just not render some data. That’s fine, better to be stale than dead. Meanwhile, app should ask for update.

So, use GraphQL non-nullable only for fields you know they will never change. For example, “webs: [Web!]” can be later replaced with “apps: [App!]” without breaking change for not yet updated apps.

Feel free to comment.

When I am teaching JavaScript and React, often my audience comes from traditional Java or C# world, so I need some sweet spot to justify all new stuff they need to learns, and, which is harder, all old stuff, they have to forget about. Such sweet spot is algebraic types. They are available both in https://flow.org and https://www.typescriptlang.org. I discovered them in the article from famous Mark Seeman http://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-types. Despite their name, they are fairly simple.

You can play with examples in Flow try.

Nice to see we can define data shapes so easily without any class syntax garbage. But there is more! We can design types so that illegal states are unrepresentable. And that’s impossible with C#, Java, and other nominal type systems. Yep, in C#, Java we have to enforce data shape in constructors with runtime only check, which is pretty brittle. …

Forms are often over-engineered. They don’t have to be. Let’s start with types. Why? Because types help us to think about architecture.

Update: In https://github.com/este/este, you will found even more simple and concise and powerful example of modern typed universal validation.

Types and validators

ValidationError component to render validation error as message

Example usage

And that’s all. It’s explicit, typed, and clean.

Is pretty dangerous pattern because if an app is terminated before the end of some async process, the form will be disabled forever. The same for every temporally value in app state.

We have to store disabled form fields state in local storage, to share app state across tabs. Separate local storage and session storage is possible, but hard to code without a lot of boilerplate.

We can filter app state after storage rehydration, but again, it’s error prone and hard to implement easily.

This is the approach I’m using in Este:

With temp wrapper, it’s almost impossible the developer accidentally forget to filter session only values.

If you like it, please donate.

If you like what I’m doing with github.com/este/este or whatever, please support further development.

Thank you.

Server detects user agent locale and returns internationalized app, if possible. Server doesn’t redirect.

With this approach, the same URL provides different content. It means, example.com/about will render both English or Czech content. I believe it’s ok because server also provides language annotations for crawlers.

Therefore, cs.example.com/about will work as expected. Both for the user and the crawler.

What about links? The same. Link from example.com/about will go to example.com/blog, while link from cs.example.com/about will go to to cs.example.com/about.

• https://johnresig.com/blog/a-strategy-for-i18n-and-node
• https://support.google.com/webmasters/answer/182192?hl=en&ref_topic=2370587
• https://support.google.com/webmasters/answer/189077?hl=en
• https://support.google.com/webmasters/answer/6144055?hl=en&ref_topic=2370587

Please comment.

Forms are hard. It’s the same as validation. No magic framework will save us from writing our app code. The wrong abstraction is the wrong abstraction no matter how hard you push the human limits.

UPDATE: I made beautiful forms without Redux. Check it 🐕✨.

Pokud vás zajímá více, pořádám školení: https://javascript-skoleni.cz

Some people, when confronted with a problem, think “I know, I’ll use some library.” Now they have two problems. Or more.