You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
🐧
Delivering high quality code, out remote! 🏔🏖🌴🇮🇱
Nick Ribal
elektronik2k5
🐧
Delivering high quality code, out remote! 🏔🏖🌴🇮🇱
A keen OSS supporter, Linux user and web platform hacker. Traveling with my family, working remotely as a front-end consultant and freelancer 🛪
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We use classes due to their superior static analysis capabilities in TypeScript. However, classes come with well known pitfalls which we want to mitigate by:
Avoiding inheritance and using composition. Use TypeScript's implements instead of extends when declaring classes:
- class MyArray extends Array {}+ class MyArray implements Array {}
In order to allow modularity, enable testability without mocking (which is always a PITA) and keep platform code out of our models, we initialize relevant fields with an explicit null value. However, the flip side is that we must also deal with these null values. The way to do that is via TS's type guards. Here's a real (partial) example:
// A nullable field which can hold a reference to a platform specific API, which may not exist in the test environment.typeMaybeStorage=Storage|null;interfaceWithLocalStorage{storage: MaybeStorage;
We use MobX to describe and keep our application domain data, mutate it in a typesafe manner and have the UI and side effects react to those mutations in a controlled way. MobX has one job: change detection and automatic reactions to those changes. It doesn't tell us how to structure our code, which abstractions to use, whether to use classes or POJOs or how to organize files.
And it is always synchronous, which is important because you don't ever need any inspection tools or debugging addons other than debugger to see exactly what's going on. The abstraction is very thin and any change can be traced directly back to the code which triggered it simply by following the stack trace. How you choose to write and structure code is 100% up to you.
MobX isn't tied to any specific platform and only requires a JS runtime. All our models should be free of any platform specific code or dependencies, such as DOM, Node, RN, React, etc. We pass our models to platform sp
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters