This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-04
Channels
- # announcements (5)
- # beginners (205)
- # calva (1)
- # cider (48)
- # cljs-dev (9)
- # clojure (123)
- # clojure-berlin (1)
- # clojure-europe (2)
- # clojure-italy (5)
- # clojure-nl (6)
- # clojure-russia (7)
- # clojure-serbia (1)
- # clojure-spec (8)
- # clojure-uk (33)
- # clojurescript (134)
- # cursive (5)
- # datomic (31)
- # emacs (5)
- # figwheel-main (61)
- # fulcro (10)
- # hyperfiddle (23)
- # jobs-discuss (24)
- # klipse (1)
- # lein-figwheel (3)
- # midje (5)
- # nyc (1)
- # parinfer (2)
- # pathom (14)
- # pedestal (12)
- # re-frame (46)
- # shadow-cljs (24)
- # spacemacs (1)
- # tools-deps (37)
- # vim (4)
- # yada (22)
What are peoples strategies for making dynamic app-db paths reusable? I have a path like this: [:app/local-storage :app/users 001 :app/devices 002 :device/some-key]
After refactoring it I've broken a whole lot of my app. To avoid this in future, anything that alters (events) any level of that path takes a customised rf/path
interceptor, and anything that queries (sub) any level takes a number of different input signals for each level. Prior to this change, each event and sub repeatedly reconstructed the path. Other options I've considered are a function that takes the dynamic segments, builds and returns the path. Also while all this makes my production less fragile to path changes, my tests are still very fragile because the datastructures are hardcoded into them. This leads me to think that perhaps the structure of app-db should be well thought out in advanced to avoid structure changes just as a relational database would. So maybe the solution is not investing too much time into allowing it to change (implementing input-signals, path functions/interceptors) but thinking ahead to prevent it changing in the first place. Thoughts?
So should I accept that app-db structure changes are unavoidably painful or is there an awesome solution I haven't thought of?
do you have a validator on your db? so you get errors as soon as something appears in it with unexpected structure? That’s recommended here: https://github.com/Day8/re-frame/blob/master/docs/ApplicationState.md#create-a-leveragable-schema
@rutledgepaulv I know it existed but I always felt there was more overhead in managing that spec than time spent debugging those problems
For example after that refactor I spent very little time debugging problems as my failing unit tests were giving me all the information I needed.
What are your experiences specing the app-db? Would you recommend it? Do you think it's worth the overhead? I've never actually tried it on a real project so it's hard to make a comparison
I took a slightly different approach than spec with an interceptor.. I just define a schema and attach a validator to the db atom
(set-validator! db/app-db (let [original @db/app-db] (fn [db] (if-not (identical? original db) (boolean (s/validate common/AppDBSchema db)) true))))
I’ve found it helpful while building my project.. helps me detect when I’ve failed to update something somewhere
but my app db isn’t huge yet
though I’d guess maybe the value increases the larger it gets? It gives me confidence I wouldn’t otherwise have
That's a good solution over the interceptor I think. I wouldn't have to pass interceptors into events or wrap the reg-event-*
functions
right. it lowered the barrier for me a little
though I guess wrapping a function shouldn’t be a big deal either 😛
And it look a lot cheaper to implement than interceptors too.
Do you run it in production or just development?
It's probably just a log right? Does it throw errors or anything?
as written that throws
for now, both. but it’s not performance sensitive since it’s an internal admin app
certainly wouldn’t be hard to toggle behind a flag
or to only log
but i like the peace of mind the hard errors offer
Yea nothing unexpected that way
yep. you can use the schemas for more than leaf validation too - like enforcing invariants across sections of the db
I'm not familiar with the terminology you just used. When you say "leaf validation" are you talking about simple validation on single attributes in the tree? And when you say "enforcing invariants across sections of the db" is that cross checking/validation of multiple attributes?
yep exactly. like if you have a collection of things that point at something in another section of the db - you could encode that as a constraint in the schema and so receive errors / warnings when your db breaches that contract
Ah okay nice. And yea that is really handy. I'm going to spec my db with your approach as it seems like a lot less overhead that interceptors.
good luck! in case it wasn’t clear - that bit about checking identity in the snippet I pasted was just to avoid the validator throwing when it’s attached since i was running that at the top level before the db has been initialized
otherwise you’d have to specify that a valid state of your db is also {}
ah okay thanks
hello reframers! I'm using reframe10x, wondering if there is a way I can avoid the debug window to appear by itself?
ah, a little snippet magic of localStorage.setItem("day8.re-frame-10x.show-panel","\"false\"")
in the index.html before loading re-frame solves the issue
I am trying to do some computation with two subscriptions in which I pass two parameters too but I can't seem to get the syntax. Any ideas?
Still waiting on a response to this.
@whoneedszzz I would suggest creating a github issue
Wait, why did you delete the link?
In any case I'm not a fan of creating issues without suggesting actual code to support the issue. I was simply asking if it would be possible because I don't know 10x's code and if it would be possible then I would try to create a PR for it when I'm not swamped unless someone else was also interested in the same (which it appears so from the issue you had linked). The issue you linked and the one linked from there talk about different approaches that don't save any time or effort than what I'm currently doing of popping it out and having to close it between each reload.
I'm suggesting adding a button next to the pop out button that simply collapses it like a Material-UI drawer
I deleted it because it was a link to an issue that wasn’t actually related to what you’re asking 🙂
Well it is actually
It's the same issue, but different approach to solving it
It's especially frustrating on mobile
That a drawer would solve very well
I don't think hiding it by default is a good idea as that tends to lead to forgetting about its existence