Clojurians Log v2

@ashnur looking at the API documentation, it seems that specs can be defined for ClojureScript, so front end code. https://cljs.github.io/api/ There are even test and gen namespaces, so I assume everything covered in the broadcast will work with ClojureScript, although I have not tried it yet. It would be interesting to see if there are any differences in writing this all in ClojureScript, I would hope it works all the same. I would be concerned as to how fast generators run, especially using 1000 checks. But for small numbers I assume it would be fine. Ideally I would write specs in a Clojure common, ,cljc file and try not to not include any host specific code. So it would run with Clojure (BE) or ClojureScript (FE). I think custom predicate functions may be the only place where host specific code would creep in and you can always define any host specific code in a Clojurescript namespace and use it from the Clojure common specs.

Definitely everything works the same. Maybe, probably, I am not making myself clear enough, please forgive this. The issue is not technical at all. I find it hard to conceptually organize specs on the frontend since most of what I should spec are not the same thing you would want to spec on the backend, and while the ratio of tools over things to spec is large on the BE, it's inverted on the frontend.

Agreed, I haven't really found anything about applying spec on the front end yet. I mainly do relatively small reagent single page apps, mainly content based rather than business logic. Adding specs doesn't immediately seem that useful. I do have some code redundancy even in simple sites, so plan to develop content generators, creating specifically shaped data structures that will render in reagent. These generator functions could have fdef specs to ensure I am getting the correct shaped output. Anywhere I am passing around data structures also seems a potential place for defining a spec, which could then be used as the argument part of an fdef spec. The more a function or data structure is used then it seems the more potential a spec would be valuable. I think it's fine just to add one or two specs at first to see how they benefit the development workflow. The more complex a UI then I imagine a greater benefit of adding specs. I plan to revisit more Clojurescript development next month, so will consider where spec could be applied.

There are infinite things to use specs for on the frontend too! Most obviously, if the views are data-driven, then property based tests can reach even complex interactions, which I don't think many people are doing even today, because it's considered too hard. But it would be nice having some way to be sure that the "content", which is the base of the value the app is shipping, exactly as you say, is visible. That is, to be able to calculate dimensions and access viewport information and match it with it. So a visibility spec could be nice. Another value is the service that manifests as a process, and it's important that some content, and some interactions, are available only in special circumstances, a kind of "linearity progression in the user flow" test. So some spec that says that something was not triggered or some data was not written between some bounds (so no infinite negation of future values). My data is simple 3 hashmaps, not even nested too much, maybe 2 levels. But it's in react hooks and I read it inside react function components (js functions basically). So, if I understand you correctly, I could perhaps start by writing just specs for the data I use in my functions now. But how can I easily run and check it? Maybe some shadow-cljs hook, or manually? The problem is obviously that doing tdd with sophisticated frontends that use css-in-js and similar advanced compilation techniques, not a very well established pattern, like tdd for web services.

But with 3 schema/specs I can give you a fully configurable form-based ui. That is, something where you can have another ui that outputs schemas/specs and then what I wrote will take the outputted specs from this ui and generate a fully functional, production ready webapp that displays the necessary forms beautifully, with full client and backend side validation if necessary, it depends at some point on the backend too. Although if you write custom predicates in clojure that kinda ruins the nicety, this is much nicer in javascript where I did this with json schema and it actually made sense. In clojure you wouldn't want to go on this roundabout way, just have the data in proper edn 😄

Well you can think of ClojureScript (and Clojure) in a very simplistic was as EDN that you can execute... I am interested to see how the clojure spec design will evolve over the next months, some aspects sound like they will be simplified. Something i'll dive into towards the end of 2020 (many other things to learn / re-learn in the mean time)

I am waiting for select like some people I knew waited for the second coming of the messiah.

I grok select, keys is hard.