If type checking is being used in this way, one would not want it to be disabled simply because
NODE_ENV=production. Another situation in which tying checkTypes to NODE_ENV is problematic is property-based testing. These tests can be slow, so one may wish to disable type checking when running such tests locally. One would not want to set NODE_ENV=production, though, as this may have other effects such as having the test runner connect to a live database. The general problem is that having different behaviours depend on a single value means one can't adjust one setting independently of the others. A better solution would be to have a dedicated environment variable such as SANCTUARY_CHECK_TYPES. In fact, there's a module named plaid-sanctuary in Plaid's private npm registry which simply creates and exports a Sanctuary module with the value of checkTypes determined by this environment variable.
In general, though, I don't think libraries should dictate a certain configuration mechanism. Environment variables aren't a good solution for front-end projects, and even for back-end projects some teams prefer config files. The easy option would be to ask users to mutate the module via
S.checkTypes = false, but this would prevent type checking from being used in one module but not another, and would cause problems for projects which depend on Sanctuary both directly and indirectly.
The current approach is certainly cumbersome, but I believe it to be the best approach of the one's I've considered. The downsides of relying on
NODE_ENV outweigh the benefits, but it's possible there's an equally convenient solution with less significant drawbacks.
I have an apartment to call "home" for the first time in three months. I'm about to put my head down and spend the weekend tackling the tasks in #255. I'll start with Murmur and go from there. :headphones:
Your work on sanctuary-set is extremely exciting to see, @scott-christopher! I love the ASCII diagrams. You're welcome to open a pull request at any point. It might be useful for discussion purposes even if you feel there's still a lot of work to be done.
:)
I'm still new to Maybe and Just types, but I'm wondering if some of this is just to make a small cohort of people who are used to functional languages that don't make use of closures feel at home using the same style in JS? If I'm doing a null check or going into a container to check, feel similar in terms of work and understanding.
My background is definitely not in languages like Haskell, I've moved from more traditional JS styles towards this sort of thing. There are definite benefits to the container types beyond just null checks. For me, being able to write functions that take normal types and assume they aren't null is a really nice way to prevent bugs. The containers (like Maybe, Either, and Future) encode information about your program into the structure, so you can know more about your values by looking at the code, and so you can write code that only deals with the specific logic it handles, while letting the containers handle a lot of the heavy lifting of validation, async vs sync, null checks, etc.
so if you break your program down into a series of functions that transform your data
R.pipe(f, g, h, i), and f might return a null/undefined, then you need to do either do null checks on g, h,and i as well (even though they are safe themselves), or you need to nest everything inside the first null check (losing compositionality)
The other question for folks using this style in production, is how do your coworkers respond to reading code/ working on a codebase written in this style?
I really like that blogpost
re how do colleagues respond: I suppose it depends on the colleagues in question, and how it's introduced :) Things like
Maybe and Either are not very common in javascript of course, but on the other hand, the basic pattern should be sort of familiar from working with Arrays and Promises
Similarly,
and
S.Just(3).filter(x => x > 3) will return S.Nothing()and
[3].filter(x => x > 3) will return []
These things sounds good, would be nice to see a nice write up /video with examples to really understand.
I agree that this would be very useful, @bgvianyc. I currently have my hands full preparing the next release, but I look forward to tackling #210 and #211 (and possibly recording some screencasts) in a week or two.
Now I can
const {$Maybe} = require('./types')
So I get access to everything but Maybe and Either. ^^
Perhaps it'd be nice to create a
sanctuary-types which exports all types currently baked into sanctuary-def, and a sanctuary-algebraic-types which exports $Either and $Maybe. Or simply export $Either and $Maybe from sanctuary the same way $FiniteNumber is exported from sanctuary-def.
Or to prevent naming conflicts:
T = {native: require('sanctuary-types'), algebraic: require('sanctuary-algebraic-types')} - you get the point. :)
But with the second approach there is more certainty that I'm using the same type definition that is in my Sanctuary environment. So it's probably the better approach.
Perhaps it'd be nice to create a
sanctuary-typeswhich exports all types currently baked intosanctuary-def, and asanctuary-algebraic-typeswhich exports$Eitherand$Maybe.
This is close to what I have in mind. I created sanctuary-types several months ago for exactly the purpose you described. I created sanctuary-either and sanctuary-maybe a few days ago. I'd like to move the definitions of the Either and Maybe types (and their associated type constructors) from Sanctuary to these separate projects. Sanctuary will then depend on these packages, but people will be free to use the data types without using Sanctuary.
