Fork me on GitHub

@roklenarcic I went ahead and took a first pass at filtering. It is on clojars at 0.2.0-SNAPSHOT of fulcro-sql. I added an argument to run-query, after id-set, called filtering. Filtering is a map of the form : {:table/column {:op value}}, where :op can be one of :eq, :gt, :ne, or :lt. E.g. {:account/deleted {:eq false}}. I did not yet add the join table data support, but I did add tests for this basic filtering. Have not added depth ranging yet. Something to play with. I pushed the changes on the feature/filtering branch for now.


Thought maybe you could play with it and give initial feedback

Alister Lee08:10:55

@tony.kay roger that - no REST on the wire. But i do want to simulate REST routing, enabling normal bookmarking, at a minimum - bidi and pushy are my friends. I'm starting from the fulcro-template (not lein-template) and so far I've added a <base /> tag so that the <script> includes work. I think the secret sauce is here:

(ssr/build-initial-state (fc/get-initial-state root/Root nil) root/Root)
(ssr/build-initial-state (fc/get-initial-state root/Root bidi-match) root/Root)
. Stand by.

Alister Lee11:10:58

Ah! so I think I need to call something like

(core/server-read env :query/posts bidi-match)
rather than
(fc/get-initial-state root/Root bidi-match)


@clojure388 So, the template already has SSR and restful support…I mean, it doesn’t have any persisted objects to display, but I see where you’re struggling now.


I don’t recommend making initial state dependent on the bidi match. Treat the initial state as just that: initial state of a shiny new app with no interactions yet. Treat a bidi match as a transform on the state. This is a transform you’re going to need to write either way…set routers to the right screen, and update app state. In the client, the transform is invoked from a mutation that is based on the match, and possibly includes triggering some reads. On the server you have the data, so it is more of a merge of that data, followed by running the same transform steps.


init-state -> merge "loaded" data -> xform


Otherwise you’re going to end up with a crap-ton of conditional logic in your initial state that is impossible for anyone to navigate or understand over time


You xforms should be much easier to deal with, because the can be easily written to go from any legal app state to the one you desire. Thus, links in your UI can leverage them just as well as bidi matches and server renders


Hm I don't understand this error: Cannot dispatch to form-field renderer on form {:person/id 36, :person/name "Rok", :person/total -43} for field :person/name


oh wait I'm missing form support initial state


So, I just pushed an update to fulcro-sql 0.2.0-SNAPSHOT. Improved filtering. See the specs and run-query docstrings for more info (on branch feature/filtering.


yeah I'll look into it after I get my modal+form working


first issue is that of course the :person-edit spot is nil initially when the application loads so ident is [person/by-id nil] and complains, not sure how to handle spots in my app that use idents but the initial state is missing


don’t include the :person-edit key in your initial state


it is trying to normalize it, but you’ve given a value of nil


yeah but the parent component has nil in that spot already


so I don't know why it's called at all


I’m saying not to use nil…don’t even put the key in state yet. Wait until something is selected


If your initial state has no one to edit, then you should not compose in state for it that will just be nil 🙂


still no dice


reloaded the page?


you may have other spots in state that have a similar problem


I gotta go…I have a scheduled thing I have to leave for. I’ll check in later


I did. Here's the state: :person-edit {:singleton {:modal [:fulcro.ui.boostrap3.modal/by-id :person-edit]}}, and the query for PersonEditModal is [{:modal (om/get-query b/Modal)} {:person (om/get-query PersonEdit)}], and PersonEdit has defsc definition :query [:person/id :person/name :person/total :person/avatar :person/active f/form-key] :ident [:person/by-id :person/id]


And then error


Invariant Violation: component ledger.ui.root/PersonEdit's ident ([:person/by-id nil]) has a nil second element. This warning can be safely ignored if that is intended.


So I don't get it, I don't have :person key at all in modal state


so why does it care what PersonEdit's ident is


This is the only usage of PersonEdit


Use get-initial-state on your root component from the REPL


The state I listed was after reload.


You’ve told it that PersonEdit is going to be a person, with an ident. You’ve then composed in the state of a person edit that has non…which is nil


or did you?


dumping the initial tree should make it a bit more clear


hm nothing about that at all in initial state


I can't make heads or tails from this


after normalization there's no :person key in that state, so that join shouldn-t be a factor


fixed it by making render conditional on the modal level


Changed render to (b/ui-modal-body nil (if person (ui-person-edit person) "PLACEHOLDER"))


Seems weird that I need to guard in render against modal rendering while it is not shown


If I want to swap an entity into the edit slot in a mutation, I also need to look up that ident in the database and use build-form to equip it with the right properties, right?