Closed danielo515 closed 6 years ago
My question is, how costly is to bootstrap a sanctuary instance ?
The cost is negligible, I imagine. The implementations are defined exactly once, so the cost of creating a Sanctuary module is equal to the sum of the costs of wrapping the various implementation functions.
const sanctuary = create ({ checkTypes: isProd, env });
If isProd
is defined as process.env.NODE_ENV === 'production'
and env
is defined as S.env
, you could use the default Sanctuary module here.
Hello @davidchambers ,
I ended wrapping the always safe version on a thunk that bootstraps it, to avoid bootstrapping it when not needed.
I'm not sure I understand your second comment. Do you mean that by default sanctuary will look for NODE_ENV
and deactivate the runtime-type-checking accordingly and that it will use the default env from S.env
? Does that mean that If I run create myself I am actually doing the same twice ?
Do you mean that by default sanctuary will look for
NODE_ENV
and deactivate the runtime-type-checking accordingly and that it will use the default env fromS.env
?
Yes. This change was made in #512. I must write the release notes for v0.15.0 to document this.
Does that mean that If I run create myself I am actually doing the same twice ?
Yes. You will need to use S.create
if you want to specify a different rule for when type checking should be enabled and/or include different types in the environment.
Yes. You will need to use S.create if you want to specify a different rule for when type checking should be enabled and/or include different types in the environment.
But then, whatever I do, the creation is being executed at least once ? Let's say that I want to add some extra env to my custom sanctuary build, does that mean that I will have my custom one and the default one exported by sanctuary ?
Let's say that I want to add some extra env to my custom sanctuary build, does that mean that I will have my custom one and the default one exported by sanctuary ?
Yes. In fact, Sanctuary exports two modules: S
itself, and S.unchecked
.
Yes, I noticed about the unchecked one. Thanks for your clarifications. They make a lot of sense for the default case I have to say. At first encapsulating sanctuary into our own internal library was to make it's usage easier. I didn't wanted that my coworkers had to take the responsibility of activating and deactivating type checking based on the environment. Thankfully it still makes sense because now I customize sanctuary with some custom types and I also export some utility functions. But the behavior you described is not obvious, and I think you should clarify it on the documentation. Maybe a small note on the creation example where you do it based on node env would be enough. Something like: please note this is the default behavior.
Regards
But the behavior you described is not obvious, and I think you should clarify it on the documentation. Maybe a small note on the creation example where you do it based on node env would be enough.
Is the following sufficient?
There is a performance cost to run-time type checking. Type checking is disabled by default if
process.env.NODE_ENV
is'production'
.
Is that on the documentation already? I totally overlooked it
It was added within the past two weeks. :)
OOO, that makes sense 😄
Hello,
I am going to create a package for internal use on my company that encapsulates sanctuary. To make things easier to my co-workers I want to export a sanctuary version that only performs type checking on production by default. However, I want to provide an easy way for using some functions that perform type-checking even on production, so you can choose which one to use. Take some allways safe functions for certain parts and non-checking functions for the rest.
My question is, how costly is to bootstrap a sanctuary instance ? My idea is to make something like this:
My main concern is about memory, because bootstrap time I understand that is negligible. If it is too costly to make it by default, I can always encapsulate the second option on a thunk, and require users to execute it to actually get the bootstrapping.
Thanks in advance.