This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (5)
- # beginners (6)
- # boot (66)
- # cider (48)
- # cljsrn (14)
- # clojure (699)
- # clojure-austin (2)
- # clojure-berlin (1)
- # clojure-boston (5)
- # clojure-dev (3)
- # clojure-india (7)
- # clojure-italy (24)
- # clojure-nl (5)
- # clojure-russia (33)
- # clojure-spec (30)
- # clojure-uk (64)
- # clojure-ukraine (22)
- # clojurescript (123)
- # clojurewest (1)
- # cursive (18)
- # datascript (44)
- # datomic (12)
- # dirac (46)
- # figwheel (1)
- # gsoc (5)
- # hoplon (6)
- # immutant (29)
- # instaparse (1)
- # juxt (26)
- # lein-figwheel (5)
- # leiningen (4)
- # luminus (8)
- # mount (56)
- # off-topic (60)
- # om (67)
- # om-next (1)
- # onyx (8)
- # proton (28)
- # re-frame (125)
- # ring (3)
- # ring-swagger (3)
- # specter (22)
- # testing (2)
- # unrepl (1)
- # untangled (91)
I construct the server-side clone of my app-state by running the client's parser on my server. This requires writing the reads in .cljc, You can see a server-side example here: https://github.com/anmonteiro/om-next-fullstack/blob/master/src/clj/todomvc/page.clj#L8 That line makes a reconciler which uses the client_parser reads: https://github.com/anmonteiro/om-next-fullstack/blob/master/src/shared/todomvc/todomvc.cljc#L80
merge-tree does a naive merge of current app state and novelty. I think incremental remote updates that would require deeper merges without disturbing surrounding values (such as with pull to refresh within some nested list component) is something i expect a lot of people to do in the future, and therefore, enough to warrant om.next supporting this out of the box. I’m thinking of implementing a smarter callback by which selective deeper merges can happen. Is this something you think is worth exploring?
the reasoning is that people will have different needs and there remains to be seen what is the best default. In that case going with the simplest case, but allowing for extension, is IMHO the best you can do
I think with the current setup,
merge-tree isn’t very extensible, as it can’t accept outside information. I tried attaching meta to the novelty hoping that I could include some
:merge-paths information that i could use with
assoc-in, but the meta is lost along the way.
Not sure I explained correctly. My initial
:state is an empty atom (client and server). I have a server-side reconciler and it calls the server reads and renders to a string fine.
Then said string gets loaded on the page, fine again.
And then fetches data from the server (again in a way), and displays the same things it initially displayed.
I would like to get rid of the un-necessary extra fetch, and more importantly the FOMD (flash of missing data) 😛
can you try alpha48 which has this fix https://github.com/omcljs/om/commit/b8922e98a7bec8e446d68419b9ef226e4e4f74f8
However I am surprised there is no way to get the data from a component, as this sounds like something you would want in a a repl-driven workflow? How do people develop om components? Like JS components except with figwheel?
Right that part is good. It goes both ways: feed data, get it in props etc. I guess something else bothers me. I have to find words to put it still - something is not symmetric with the query mechanism like it is with the props. Could be lack of om knowledge on my end though.
@nha if you are trying to inspect something during development time, you can use the React Tools on chrome to visually pick an element on screen (it will be $r on JS), with that you can get props with
om.next.props($r), or anything else you want to do with the component
@anmonteiro We're trying to navigate after a successful call to the remote server. Do you have any thoughts on how to do that in Compassus? I don't have access to the application in
send, so I can't call
set-route!. Although I could rearchitect it to close over the application when the app boots. Would that be appropriate?
send be allowed to see the application/reconciler? Or should I be finding some way to pass a callback of some kind into the
send for it to call after the response comes back from the server?
I really kind of want to know which component transacted it. Or, really, I want to component to decide what to do
Under what conditions might one expect
(path component) be
nil? Trying to track down an issue and finding that it's
nil when called in
default-ui->props in om src.
The are a couple of use cases we've got: one is that when you successfully create something with a particular button I want to navigate you to that thing
the other is that we want lots of buttons to show that they're "working" while the request is out
@peeja so at Ladder we use a function called
normalize (I know, poor naming choice) that runs inside
bnoguchi: this may not be the case, but I’ve seen
(path component) fail when rendering child components with
map instead of
i.e. redirecting to a route after a remote mutation returns, stopping to spin a loading button, etc
Like, if you have two buttons that both do the same thing on the page and you click one, do they both spin?
since it doesn’t make sense to click one if you already clicked the other which does the exact same thing
bnoguchi: yeah, i was calling
map instead of
mapv (non-lazy). i think the
map interacted with the dynamic vars that track the om.next path in weird ways. i didn’t really debug it much, though
@matthavener Do you recall where that fn
path is defined? Only one I could find was in om.core, but that seemed related to cursors and not imported to next.cljc
@matthavener Figured it out. The culprit was invalid query syntax (for a parameterized join). The parser could consume the invalid query and returned the expected read but the broken syntax broke how