Clojurians Log v2

i have a similar problem to yours on the frontend, when i want to write a form generator, I have to keep 3 different specs for the same entity 1. the remote state specs that the backend API expects to get when I put or post or update the resource 2. the ui state specs which contains invalid data that was inputted by the user and is fully controlled by the user, but it still needs to be validated and used 3. my local display state specs about the inputted resource that holds stuff like a list of strings to shown in a predictive input while the user is typing their stuff it's all in the same Entity! the only solution is to accept that actually no, these are separate entities and require separate specs with separate names. similarly in your case, if your context is different then you need a new spec

is "specs are not contextual" the same as "if your spec depends on context, you have more than one specs"?

@ashnur spec 2 makes selection contextual (e.g. the combination of required keys)

but the keys themselves are always globally described

not allowed to use spec2 in production yet afaik

true, for practical purposes it doesn't really exist yet, but this is one of the biggest issues they wanted to address I believe

i am not sure it's the same issue

the same logic goes for selections as well, if your selection depends on the context, isn't it true you have more than one selections?

yes, so?

i am good 🙂

you don't even have to remove the old one :)

exactly

It's a paradigm shift and sometimes takes time to finally get it.