4 ms·
Hi. Thanks for the workaround, it's fairly similar to how it's handled in TS, except more verbose (which TS is already very much so when compared to something l
by mixedCase 8y ago
Hi. Thanks for the workaround, it's fairly similar to how it's handled in TS, except more verbose (which TS is already very much so when compared to something like Elm). That isn't a problem for me since I have some experience with functional programming, but that'll likely be a serious disincentive for other devs (TS itself has been a problem already). Maybe I'm off the mark and that is idiomatic and a very common Dart pattern, and can be assimilated through familiarity?
On another note, is there any workaround to have true non-nullable types?
As far as the cost of having one codebase goes, right now it's somewhat of a worse is better approach; we're looking into something that heavily improves things and is worth rewriting our apps into. RN hasn't been it due to its FFI/bridge problems not making us comfortable and Flutter is something we've been looking into but the language has been a deterrant, so it's hard for us to argue "yes it's better on every metric and worth the effort".
- jrs95 8y agoDart has had some null-aware operators for awhile (https://news.dartlang.org/2015/08/dart-112-released-with-null-aware.html https://news.dartlang.org/2015/08/dart-112-released-with-nul...) otherwise you'll need to explicitly do null checks. It's certainly not perfect, but it's still "good enough" to make handling null relatively concise. In my experience code review can do a good enough job at promoting good practices around null handling that non-nullable types are really just a "nice to have".