@gdeer81 Sorry for the delayed response. defsub currently requires either a let block followed by the map defining the subscription or just a map. Not sure if that explains anything you were experiencing though.
The issue where the category filter dropdown was updating the price filter dropdown was because I was using the wrong keyword
I have found that renaming, commenting out, or deleting rules (meaning any rule construct --- define, defsub included) requires a hard restart of figwheel, and that reset-autobuild doesn’t work. I’m not sure why that is. I’ve been working on a fix for that this morning but it’s a bit tricky in CLJS with macros. We basically need to recreate the session, which is something that happens at compile time, and I’m not sure how to force recompilation. I’ve made some progress with unmapping the rules so we can at least avoid restarting figwheel. The page still must be refreshed though, so I’m working to fix that and so the state doesn’t get blown away.
So redefining/recompiling the session with a repl command is the challenge now, and avoiding page refresh. If we can get there, then I already have a way to add the facts back to the session, clear the indexes, so you can resume where you left off
Frontend development isn’t my favorite either. I think the reason I prefer backend has a lot do with good reasoning being rewarded. I’ve definitely experienced that with Precept, where things “just work”, seemingly in spite of myself. But overall yeah, I think frontend and Clojurescript is thornier, especially at the framework level. We’re trying to abstract that away somewhat by just having subscriptions and rules. I was kind of surprised to see how little logic we ended up doing inside the view layer. It was basically just markup and subscriptions/data bindings
Also working on the CLJ implementation much more than we have so hopefully some good changes will happen there too
Already I think we’ve got the CLJ implementation of something like REPL driven development workflow. The solution I’m gunning for in CLJS came together fairly nicely there. With a repl command, you can reload all rules and have the state right back where you were plus any changes from the rules you may have redefined or removed
Yeah, I thought the idea of using mount was so you can wrap those kinds of stateful things and get back to a clean point whenever things get hairy
That’s a great point…thanks, I think I’ll look into that more. I’m still not familiar enough with RDD and libraries like mount and component
Thanks so much for providing this detailed feedback. I can’t tell you how valuable it is to me 🙂
It's my pleasure. Also, I shamelessly ripped off your example fullstack app for my own experimentation: https://github.com/gdeer81/shoes
Woo!
Precept-o-licious kicks
lol yeah my friend is a shoe fanatic so I wanted to experiment with the idea of having a developer and a domain expert work together. She's a developer as well but not familiar enough with clojure or clojurescript to want to work on this project as a developer. So she's my product owner and domain expert; can she give me complex shoe rules that I can translate into clara rules? that is the question
Lol
That’s great haha
also I saw a talk on clara rules where someone had a tool that explains why rules fired and even a visualization of all the nodes. have you talked to jason gilman about tooling and visualization? When he first saw Saiyid he had that working and visualized in protorepl in no time.
have you had issues with precept.state/store not initializing correctly?
I should write a post startup validator; no products in the store is a definite issue
also am I doing this right? I have a rules.cljs and a rules2.cljs file and in rules.cljs I have (session app-session ['shoes.rules 'shoes.rules2] :db-schema db-schema :client-schema client-schema)
It didn't like that. When I switched back to just a single namespace for the rules everything started working again
Another issue I've been able to reproduce consistently is the "Conflicting logical fact" error. It says that my sort function would produce identical e-a consequences. This seems to happen when I have filters selected and figwheel recompiles. My "solution" is to modify a clj file to trigger a clojure recompile since I'm too lazy to spin up a repl and call mount/restart. Then refresh the page and the session is good again