DEV Community 👩‍💻👨‍💻

Discussion on: The Case for TS+

Collapse
 
ninofiliu profile image
Nino Filiu

So when programming a user needs to know exactly which module to import, exactly which functions are constructors of the datatype and which are methods for the datatype, and exactly how to use them.

That I really don't understand. I'm not familiar with IO or Effect but for example in lodash when I wanna use cloneDeep I'll just do import cloneDeep from 'lodash/cloneDeep';, yeah I have to know which module to import but it's not giving me a headache. Also there's no constructors and no additional methods, and the use is evident. So I don't see any case where a similar lib would cause these issues

Collapse
 
mikearnaldi profile image
Michael Arnaldi Author

Sure you can use directly lodash and direct imports, the problem becomes more apparent when using libraries that cover a bit more surface compared to lodash (like Effect, like fp-ts, etc) and in many codebases that translates to a large set of namespace imports import * as F, when using F you have everything inside and discoverability is problematic. For example only the Effect module in effect-ts provides 1000+ functions inside (they are all as you say "just functions") but you have to know what the "just functions" do, i.e. is the function constructing an effect or is a function combining? i.e. map combines, succeed creates