5 ms·
The author talks about Immutable.js, but doesn't mention Records, which have been a real godsend in my application. I use Immutable.Record with types [1] (using
by nathan_f77 8y ago
The author talks about Immutable.js, but doesn't mention Records, which have been a real godsend in my application. I use Immutable.Record with types [1] (using Flow), and I feel very confident with this setup. You are forced to set default values for every key, and the code will crash if you try to set a key that hasn't been defined.
It's really great to have typed Records (often nested), and I expose the getters as regular properties so that I don't have to call "get()" all the time. I agree that it's not perfect, but it's miles ahead of anything I've worked with in the past (at least in terms of JavaScript.)
JSON schemas are awesome, and I like the idea of validating types at runtime on the front-end. I already have a JSON schema that defines my API (I use Swagger), so I could even go one step further and auto-generate my typed Records directly from the schema. I'll get immediate feedback about any type errors in my JS codebase as soon as I make changes to the API. I generate my Swagger API specification automatically from some RSpec tests (using rswag [2]), and I also run Flow during CI, so this would result in a broken build. I could also make this work with the data I'm inlining in the HTML to hydrate the Redux store.
Random aside: I also have a one set of data that just gets dumped into a jsonb database column, so the schema for this specific data is only being defined by the front-end code. In my backend I'm always careful to provide a default value, but it's not really critical data. Anyway, I just realized that I should be defining this jsonb column as an actual model, but instead of ActiveRecord, I could use ActiveModel and a plain Ruby class. That's a neat idea. It would give me a schema and validations on the backend, while still having the flexibility and performance of storing everything in a single json column.
[1] https://gist.github.com/glenjamin/75a96b45f4bb5c6ac221815d28c548dd https://gist.github.com/glenjamin/75a96b45f4bb5c6ac221815d28...
[2] https://github.com/domaindrivendev/rswag https://github.com/domaindrivendev/rswag
- azernik 8y agoProbably the reason is that reasonable Flow types for Records aren't in the mainline 3.0 release, and 4.0 (with good static typing support) has been in RC hell for about a year and a half.
- scns 8y agoWith Bucklescript/Reason you get typesafety, immutability, performance and small codesize: >Now we compare the runtime performance: BuckleScript Immutable Map: 1186ms Facebook Immutable Map: 3415ms We also compare code Size: BuckleScript (Prod mode): 899 Bytes Facebook Immutable: 55.3K Bytes source: https://github.com/BuckleScript/bucklescript/wiki/Why-bucklescript-matters-for-Javascript-platform https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...
- tybit 8y agoI’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.
- Scarbutt 8y agoThank Bucklescript.
- nv-vn 8y agoOCaml as a language is so close to a sweet spot between performance and ergonomics in my experience. I'm not sure if the Bucklescript compiler is generally running on Node or natively, but that could also be a big variable at play here.
- PascalW 8y agoAfaik it's native. The `bs-platform` node package contains native binaries.
- scns 8y agoregarding records specifically: https://medium.com/@javierwchavarri/performance-of-records-in-bucklescript-ecf6566fff5c https://medium.com/@javierwchavarri/performance-of-records-i...
- incadenza 8y agoThis all sounds great but I cringe a bit at yet another layer of abstraction in an already insane JS tooling ecosystem. It seems like half of the time you’re just using the escape hatch to plain JS to stitch all of this stuff together, no?
- davedx 8y agoRecords is also how elm deals with JSON serialization IIRC.