Question: Extract "validation keys" logic from core/build implementation

[tangrammer]

Hi folks!
I'm trying to add support for resolving async dependencies (js/promise so far) before injecting them in the related dependent components.
The idea in my repo would be to overload core/build to add resolve and reject callbacks but also being able to reuse the validation keys logic.

So the thing I'm asking is: could it make sense to refactor this validation logic and extract it to its own (private) function?

Here my attempt master...tangrammer:master

Thanks in advance for this great library!

[weavejester]

Can you explain why you want this? If a component depends on a promise, why not return a promise in turn? Is it that you want a way of unwinding the dependencies on failure?

[tangrammer]

Hi @weavejester !

Can you explain why you want this?

yep! in our case one component makes js/fetch to retrieve a simple map of data that other components are waiting for. It's true that everyone could expect the promise instead of the data map, but we think it could simplify a lot the code of the other components, avoiding the async context there.

[weavejester]

I don't think adding extra arguments to build is a good path forward. My temptation is to write a build-async instead, but I'm not sure of the best way to model async promises in Clojure in a platform agnostic and idiomatic way.

[tangrammer]

yep! I agree that build-async sounds like a much better option.

About platform agnostic and idiomatic way of modelling async promises ... perhaps we can follow https://clojurescript.org/guides/promise-interop so finally use clojure.async in both platforms