They are based in Oslo so they on the same time as me. Now it's almost 23, so I doubt they will be there.
The util module is only used to access util.inspect.custom in order to customize the representations of def-defined functions in the REPL.
Hmm.. could it be easily polyfilled instead of using the entireutilmodule?
util.inspect.custom to Symbol.for('nodejs.util.inspect.custom'), since I don't even know where it is used.
We could use Symbol.for('nodejs.util.inspect.custom') in every environment, but I don't like this (emphasis mine):
The
Symbol.for(key)method searches for existing symbols in a runtime-wide symbol registry with the given key and returns it if found. Otherwise a new symbol gets created in the global symbol registry with this key.
Symbol.keyFor requires a Symbol, which brings us back to square one. You can only test if Symbol.for('nodejs.util.inspect.custom') is correct by having access to util.inspect.custom.
'nodejs.util.inspect.custom'.
typeof process === 'object' && process != null && process.versions != null && process.versions.node != null
Current approach:
var inspect = typeof util.inspect.custom === 'symbol' ?
util.inspect.custom :
/* istanbul ignore next */ 'inspect'; wrapped[inspect] = wrapped.toString = always0 (typeSignature (typeInfo));Alternative approach:
wrapped.toString = always0 (typeSignature (typeInfo));
// Node.js
if (
typeof process === 'object' &&
process != null &&
process.versions != null &&
process.versions.node != null
) wrapped[Symbol.for('nodejs.util.inspect.custom')] = wrapped.toString;
// Deno
if (
typeof Deno !== 'undefined' &&
Deno != null &&
typeof Deno.customInspect === 'symbol'
) wrapped[Deno.customInspect] = wrapped.toString;util anywhere. :)
@davidchambers This is a continuation of https://gitter.im/sanctuary-js/sanctuary?at=60c62e2dd20143617e424437 and https://gitter.im/sanctuary-js/sanctuary?at=60c63e19d855766185d6112c.
I need to create Date objects of my custom data type. Right now, I'm wondering what would be the best implementation. It's rather simple really. I got a $.RecordType:
{
endDate: $.NonEmpty ($DateIso),
startDate: $.NonEmpty ($DateIso),
}where $DateIso is:
const $DateIso = $.NullaryType
('DateIso')
('https://www.firefund.net/')
([$.String])
(x => /^\d{4}-\d{2}-\d{2}$/.test (x))When ever I receive an data object for the database, I test the data with:
S.is (recordType) (x)Where recordType is the previous mentioned $.RecordType.
The entire flow is super nice and simple as:
// createNewProject :: Object -> Future a b
const createNewProject = S.pipe ([data => Table.insert (data), run, execute])
// validateNewProject :: Object -> Future a b
const validateNewProject = S.pipe ([
S.tagBy (schema.validate),
S.either (reject) (createNewProject),
])The problem with the solution above is that the database needs Date objects and not a date string (which I will get from a JSON feed) e.g. "2021-04-30".
My question is, if there is a clever way to use sanctuary-def to convert the string to Date or if I should convert the two fields explicitly in the function that calls validateNewProject? The former would be a generalization and the latter would have to be a concrete implementation to that specific data object.
// validateCampaign :: Object a -> Either a a
const validateCampaign = S.pipe ([
S.tagBy (schema.validate),
S.map (campaign => {
campaign.endDate = new Date (campaign.endDate)
campaign.startDate = new Date (campaign.startDate)
return campaign
}),
])
// insertCampaign :: Object -> Future a b
const insertCampaign = S.pipe ([data => Table.insert (data), run, execute])
// createNewCampaign :: Object -> Future a b
const createNewCampaign = S.pipe ([
validateCampaign,
// @ts-ignore
S.either (reject) (insertCampaign),
])Thanks for the feedback @davidchambers ! Much appreciated. While I understand the benefits of immutable data I find it difficult to justify all the time.
// validateCampaign :: Object a -> Either a a
const validateCampaign = S.tagBy (schema.validate)
// insertCampaign :: Object -> Future a b
const insertCampaign = S.pipe ([
campaign => {
campaign.endDate = new Date (campaign.endDate)
campaign.startDate = new Date (campaign.startDate)
return campaign
},
data => Table.insert (data),
run,
execute
])
// createNewCampaign :: Object -> Future a b
const createNewCampaign = S.pipe ([
validateCampaign,
S.either (reject) (insertCampaign),
])Above insertCampaign mutates the data to be inserted. So the issue here would be if the callee of createNewCampaign expect endDate and startDate to be String and not Date, right? Or am I missing the point?
In general it's a good idea to define as few impure functions as possible.
I suggest this approach:
const insertCampaign = S.pipe ([
campaign => ({
...campaign,
startDate: new Date (campaign.startDate),
endDate: new Date (campaign.endDate),
}),
Table.insert,
run,
execute,
]);If for some reason it's necessary to mutate the function's argument, I suggest renaming the function something like UNSAFE_insertCampaign or mutateThenInsertCampaign.
I see. Yeah, that would be difficult to track down.
In OOP you would have something like below:
const y = new Y
y.f (x) // <- mutate and own x
console.log (y.getX ()) <- you should only get x from an accessor, since y now owns x.But I have been down that road and somehow, even when trying to abide SOLID principles, a change to a business rule means changing a lot of class methods. And after a few times, it all feels like cruft and a re-write seems like a better and better idea.