This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # announcements (11)
- # asami (6)
- # aws (26)
- # babashka (17)
- # beginners (119)
- # bristol-clojurians (7)
- # chlorine-clover (2)
- # cider (3)
- # circleci (1)
- # clj-kondo (10)
- # clojure (127)
- # clojure-australia (3)
- # clojure-dusseldorf (5)
- # clojure-europe (135)
- # clojure-france (5)
- # clojure-nl (8)
- # clojure-uk (6)
- # clojurescript (103)
- # clojurewerkz (1)
- # crux (22)
- # css (2)
- # cursive (5)
- # datalog (5)
- # datomic (36)
- # emacs (3)
- # events (2)
- # figwheel-main (3)
- # fulcro (1)
- # graalvm (3)
- # helix (31)
- # jobs-discuss (4)
- # leiningen (1)
- # london-clojurians (1)
- # malli (17)
- # off-topic (2)
- # parinfer (10)
- # portal (1)
- # re-frame (48)
- # reitit (2)
- # reveal (12)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (4)
- # vim (4)
I just posted a lein re-frame template based question to #clojurescript if anyone has a moment to look at it.
Can someone help me with
re-frisk ? I am learning
re-frisk helped me a lot during app development. There is this call:
(re-frisk/enable) which puts the debug window into my application. Which I do not want to add in the production version, only for the development. Probably I need to add an
enable, but I am not sure what should be the condition. Just guessing here: I have a figwheel.main based leiningen project: I have
dev.cljs.edn and I can probably create a
prod.cljs.edn too, which could carry build information. But me seems these are intended for figwheel.main, and I am not sure their content is available directly in my application.
Is there any easy way to make
(re-frisk/enable) conditional without creating a separate configuration file and read it's content?
Thank you for the idea! I am not entirely sure how this works, but according to the comment in the source code: the idea is that it defaults to true, but if I used advanced optimization, this will somehow turn to false automatically. Neat! I try this out.
The rise of asynchronous apis is a point of friction for re-frame. Possibly an inherant conflict of "state in memory" vs "state accessed via async".
Some kind of Promise friendly cofx might help. On react native the sqlite database and keystore apis are fast but promise based.
It's still possible to use things that re-frame offers in an async environment. But it will definitely have some boilerplate. But I'm not sure what you mean by "state accessed via async".
Perhaps "data sources" is a better word than "state" since that tends to imply the app-db in re-frame.
I agree it's possible... but if you're doing it in event handlers you're moving towards a more verbose version of the origial JS "callback hell". One option is to bundle things up as fx handlers. Another is the async-fx lib (sometimes).
I think cofx returning a promise and delays event execution until it resolves is an interesting idea.
I'm storing an api token in keystore. That means to use the token I need to pull it out via an async api.
So to avoid this in every handler which needs it I have choices 1. put it in app-db (keep in memory) 2. make all api calls reach into keystore directly (promise chain) 3. register two handlers the first to request data, the second to process
Actually, I just started to remember how at the very beginning of my path with re-frame I was reading about IndexedDB and I couldn't quite reconcile the two things in my mind.
I think there's a argument that we have the necessary building blocks and that the convenience of chaining promises comes at the price of being more complicated (complected) and thus more difficult to test and reason about.
Chaining promises is one thing. Using a plain promise as a data source is another. I would argue that the latter is acceptable.
I'm a bit more ornery in that I believe that just events are too low-level for app building
re-frame's event system is nice from a perspective of purity, but IMO an event system should be something we strive to build higher-level abstractions on top of
unfortunately, re-frame's API, docs and general guidance encourage developers to use re-frame events as the language they use to implement their app, which makes common things like accessing a piece of data asynchronously tedious and error prone
promises are wonderful abstractions for a huge amount of use cases; they are composable (events: must build your own composition), they are completable and failable (events: must build your own completion and failure mechanisms), and have an identity (events: must build your own way of identifying between different occurrences)
unfortunately they lack cancellation, which events can get you... if you build it and all of the other things 😄
I've seem a few FSM libraries built [with support]for re-frame. Or just libraries that remove the need for some boilerplate. This one just yesterday: https://lucywang000.github.io/clj-statecharts/docs/integration/re-frame/ Others: - https://github.com/ingesolvoll/re-chain - https://github.com/Guaranteed-Rate/re-flow There was another one but I didn't save it - I remember not liking it because it heavily relied on side-effects in event handlers. Should've still saved it though. But I haven't used any of them yet.
statecharts is an area I think we're still trying to find the right approach with, with regards to what level the APIs should act on. Definitely warrants more exploring though. Some more libs with statecharts+re-frame: • https://github.com/MaximGB/re-state • https://github.com/jiangts/re-state And finally, re-frame EP about general state machines, seems @U051MTYAB is leaning towards behavior trees instead of statecharts though, at least from what I gathered from a podcast he was in, talking about re-frame: https://github.com/day8/re-frame/blob/master/docs/EPs/005-StateMachines.md
also, good general introduction to statecharts and how they can be beneficial: https://statecharts.github.io/
Thanks for the links. Also, not sure if it's the same lib I was talking about but
MaximGB/re-state definitely does dirty things.