This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-26
Channels
- # aws (1)
- # aws-lambda (16)
- # beginners (8)
- # boot (2)
- # cider (4)
- # cljsrn (9)
- # clojure (137)
- # clojure-italy (3)
- # clojure-russia (39)
- # clojure-spec (34)
- # clojure-uk (33)
- # clojurescript (44)
- # core-logic (11)
- # cursive (27)
- # data-science (16)
- # datomic (52)
- # duct (1)
- # emacs (1)
- # figwheel (2)
- # fulcro (90)
- # graphql (3)
- # hoplon (7)
- # lambdaisland (2)
- # leiningen (23)
- # lumo (1)
- # off-topic (1)
- # om (40)
- # onyx (44)
- # re-frame (116)
- # reagent (3)
- # shadow-cljs (87)
So, as an unofficial thing: I’m strongly considering dropping Om Next as a dependency. I’ve written a SNAPSHOT version of Fulcro 2.0 with internals that are based upon it, but simplify it and fix a number of things. I’ve been trying to find a way to patch Om Next itself, but the changes I want to make are just too invasive, and I think we can get a better result by dropping the baggage Om Next has related to pluggable dbs (we don’t need it, but it complicates things quite a bit). I’ve pushed fulcro 2.0.0-SNAPSHOT and a companion snapshot of fulcro-spec to clojars. *THIS IS NOT a production-ready version. I want to put it out there * See https://github.com/fulcrologic/fulcro/blob/2.0/README-fulcro-2.0.adoc
I’ve run it against all of the existing demos, cards, tests, and the template. I know of the following two things that are broken: 1. Server-side rendering (building initial state) 2. component-local state updates may cause children to look as if they go back in time.
this is cool
I’d love it if anyone wants to try it out. I’d be particularly interested in benchmarks.
The query engine should have less overhead, though the UI refresh could possibly be slower. I’m hoping the trade off results in generally faster overall performance
There is a 2.0 branch of fulcro-template that has already been ported as well…but with SSR disabled
Hopefully your new freedom will let you improve routing behaviour
@roklenarcic what’s wrong with routing behavior?
filling up initial state
only grabs the first route
and router's ident "eats" the ident of the component that's at route top-level
I've always considered routing in om.next a bit hacky
as far as I know routing works perfectly without any problems. If it is broken, it is a bug in Fulcro. Assuming you’re talking about defrouter
No, it works
It's just a bit.... opaque
as far as I know routing gets all routes state into initial app state, and nothing gets “eaten” that I know of
I guess I was doing something wrong then
defrouter
I'll test some more
ok. just so you know, nothing about Om Next should be breaking that one. The dynamic router is technically wonky, but also unfixable without making Om Next’s dynamic queries serializable (thus the desire to fork)
With Fulcro 1.0 if you do code splitting and use dynamic router (or dyn queries at all) you lose support viewer, and hot code reload gets ugly.
I guess I need to work out how to manage normalisation better. Here an example of what I was doing today: I tried to show person edit modal. So I made a mutation that assoced into [:person-edit :singleton]
{:modal-item [:person/by-id 5]}
. That was missing modal initial data, but if I just added b/Modal
initial state to that person in another mutation, it wouldn't work because modal state wasn't normalised to fulcro.boostrap..../modal-by-id
table. So I had to unpack the person into tree form, add modal initial state and then move it back into db form, by writing this:
`(defn update-comp-state [old-state comp ident update-fn]
(as-> (om/db->tree [{ident (om/get-query comp)}] old-state old-state) data
(get data ident) (update-fn data) (fc/merge-component old-state comp data)))`
now it works
Did you follow the example in the devguide? You should have your editor overlay the person
I had that initially and it worked, but then I wanted to display name of person in modal header
you can totally pull the data out and put it in the header without changing the query
you mean pull the name from joined in person in props?
I felt I was breaching the old "this component shouldn't know about structure of things in subqueries"
then when subquery changes it can break the parent component
from a composition perspective, you need to ask the child for the query. That is true. The parent, however, always has to know stuff about its immediate children: which component they are, and which factory to use to render them. There is no secret there.
The child should not know anything about the parent, because that would break things in unpredictable ways (the child can’t see all the parents that might use it)
That’s why children give out well- known callbacks. It lets the parent control the known relationship
So, while it is true changing a child query could break a parent, it is somewhat unlikely…and also relatively easy to debug
the general contract of a component’s class is “I edit a person” for example…is name really going to disappear from that?
I guess. Here's a question, given this router: (ident [this props] [(-> props :modal :db/id) :singleton]) :warning-modal WarningModal :edit-modal PersonModal) Is it possible to have router ident vary in the second element of ident rather than the first one?
nope…it can vary in both, but the “kind” has to be the first element of the ident. It’s how union queries work
Thought so. Thanks
Best you can hope for is naming your modal types in a more visible way…like :MODAL/WARNING
I also wish I could specify an ident as a transact! follow up read
Really? Because I got error 2 is not ISequable
when saying [:person/by-id 2]
as a follow-up
let me check again
cool, I didn't knew that 🙂
Then it sorts them by UI depth, and renders the ones closest to root first. If that covers some of the others (e.g. they are children), then that prevents the overhead of running extra queries and refreshes for them.
What's the easiest way to find out which component is lacking the react key that things complain about?
two possibilities…the message itself, if read carefully, does tell you a lot. BUT, there is a little annoyance in Om Next’s internals that can cause that warning on built-in factories… @wilkerlucio could you remind us what that was?
I see a couple of :keyfn on things that don't get any props?
I says that a div lacks it in a component that has a lot of divs 🙂
Hm... (b/ui-modal-footer nil (b/button-group {:key "modal-btns"} (b/button {:kind :success} (tr "Save")) (b/button {:kind :warning} (tr "Cancel")))) Button group needed key or else warning
Yep... b/ui-modal-title, b/ui-modal-body, b/ui-modal-footer all require keys on their children, even if it's just one
I seem to remember there was no way for me to work around that because of the Om Next issue…it’s somewhere in the chat history on here 😉
@tony.kay the apply to accept children
the problem with the current Om.next factory, is that it is sending the children as a list
and if you taht with React, you have to specify the key for every element on the list
this is ok for actual lists of items
but it's annoying when you are just rendering a fixed list of elements (and react supports that without requiring key)
the fix is to call apply
on the js/React.createElement
so the items are passed as positional items, and not a list