Using text files for styling? There was unofficial proposal for apply directive, but it died. Maybe some text files preprocessor has a similar feature, but from my perspective, untyped text files for styling is leaky (a lot) abstraction.
Happy coding (without unmanagable CSS text files mess)!
Update: Check github.com/este/este for the latest implementation.
OK, it’s not so easy but isn’t hard neither. Check este-typescript for tips.
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.
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.
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.
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.
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 🐕✨.
Some people, when confronted with a problem, think “I know, I’ll use some library.” Now they have two problems. Or more.
UPDATE: I revamped design slightly and implementation a lot. Check Este next branch.
UPDATE 2: This article is obsolete. Follow github.com/este/este for updates.
For years, developers have been fighting with complexity and related bugs of cascading style sheets. I have seen many styles, written in dozens various methodologies or without, worse or better, but almost always hard to manage and scale without rigorous supervision. Despite Less, SASS, and the other CSS preprocessors aimed to help, something was still broken in the land of styles.
For me, the eye-opener was famous “React: CSS in JS” talk. …