Clojurians Log v2
re-frame
i work on a pretty large SPA backed by re-frame. recently we caused a bug where a layer-3 subscription was expecting a map with a certain shape from its signal subs, but an expected key was no longer there because that underlying sub had changed in another commit, causing it to return incorrect data. seems like it would be nice to add types or similar to subscriptions to create a contract. has anyone used e.g. malli, spec, schema, typed clojure, or anything else to deal with this? like it/dislike it? anyone think this is a bad idea and subs should remain untyped? would love to hear strong opinions
In this regard, none of the re-frame stuff is any different from regular Clojure functions. So unless you add contracts to all or most your Clojure functions, it probably makes little sense to do so for re-frame things.
I've made this little wrapper for reg-sub. it works with layer-3 subs that have a computation function
(defn reg-sub-with-specspec arg. spec is a malli schema that is
used to validate the value returned by the subscription.
Throws the malli validation error if validation fails.
NOTE: nil values are not validated. It is probably a
good idea to allow nil"
[query-id & args]
;; Find spec arg
(let [[spec args*] (extract-spec args)]
(if ^boolean goog.DEBUG
(if spec
(reg-sub-with-spec spec query-id args*)
(apply rf/reg-sub query-id args*))
(apply rf/reg-sub query-id args*))))
Sorry, can't paste code properly on my phone
@olivevaughncode you can probably just make your own typed/contracted subscriptions, that would wrappers around the original rf/reg-sub. I made such wrappers with some success, although subscription result caching requires some detailed attention.
Hello re-frame community! I’m looking for a re-frame/Clojure[Script] expert to audit a re-frame / Firebase / polylith app and give us expert opinion on what to improve and what direction to choose. One time gig. Company http://Tallyfor.com NDA – Yes. Reward: cash + possibly some stock, or maybe even stock-heavy. Please recommend candidates. What we need I need some kind of general code quality vetting for the CEO. I believe I’m the only person on the team who worked as Clojure / Re-frame developer prior to this employment. So I think I have the most experience, but the CEO cannot attest me himself. Vetting would go like: • take a peek at a few different modules written by different devs. not knowing who wrote what, it will be detached from GH repo. • Write a list of pros and cons for each module. • Suggest a way by which we can move ahead, towards better components, Polylith and AI-ability. • Choose the best module, not knowing its author. Should be a 2 day gig.
@p-himik I need some kind of general code quality vetting for the CEO. I believe I’m the only person on the team who worked as Clojure / Re-frame developer prior to this employment. So I think I have the most experience, but the CEO cannot attest me himself. Vetting would go like: • take a peek at a few different modules written by different devs. not knowing who wrote what, it will be detached from GH repo. • Write a list of pros and cons for each module. • Suggest a way by which we can move ahead, towards better components, Polylith and AI-ability. • Choose the best module, not knowing its author.
Can't take something like this on myself since you probably would want for the person to spend multiple hours on this and I can barely master 3 hours per week at the moment for work like this. But in case it's helpful, I can say that, if possible, the description should be more detailed and to the point. Since you've posted it in #re-frame, I'd assume for example that Firebase is entirely irrelevant - whoever ends up helping you probably doesn't have to be an expert in Firebase or even know what it is. Just the fact that it has an async API is probably enough. Harder to say anything about Polylith - I haven't used it myself but it seems to me that the required proficiency depends on how exactly it is used w.r.t. re-frame and anything else you would like to get help with. Also, a bit suspicious that you mentioned Clojure-not-Script. Do you use re-frame on your Clojure backend? Or do you need an audit of your backend Clojure code that doesn't use re-frame? The size of the relevant parts of the code base would also be helpful, at least the orders of magnitude. Another useful metric is how many people have worked on that code before. Finally, if you have specific pain points, any candidate would benefit greatly from knowing them. Of course, you might not want to just publicly disclose everything. But mentioning some generic ones, or even saying that you have specific issues that would be disclosed later would already be helpful. Otherwise it's a pig in a poke - can't even gauge whether I myself would be interested if I had time.