btw your bootstrap devcards are broken for me
https://fulcrologic.github.io/fulcro/guide.html#!/untangled_devguide.N10_Twitter_Bootstrap_CSS
@roklenarcic Seems to be fulcro tutorial. Can write in the #fulcro
channel. Pretty sure Tony will fix it asap š
@roklenarcic Seems to be working on the repo. Probably needs a redeploy. You can just clone git@github.com:fulcrologic/fulcro.git
and ./run-devguide.sh
until that gets redeployed on the website.
are om.next static fields really not meant to be accessed in clj?
@levitanong what do you mean ? If referring to static/IQuery
should work on server also as far as I know (om.next/get-query MyComponent)
@claudiu Not at all. You can do static field some-name 42
and then you can access it by (.-some-name MyComponent)
I was trying to use it āserverā side to generate styles from co-located component styles, but it kept complaining the field didnāt exist.
I checked next.cljc
and it seems they left out the fields from defui-clj
ahh think I ran into this. In the om-next there seem to be a few conditionals like https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L774
have you tried https://github.com/ladderlife/om-css or https://github.com/fulcrologic/fulcro-css ?
I wasnāt too satisfied with ladderlifeās implementation because they seemed to keep the styles in the cljs side
but I havenāt seen fulcro yet. Will check! Thanks for the heads up, @claudiu
Ah, itās similar to something I made myself, it seems. XD
but fulcro has a convenience method for composing styles upwards
@levitanong ladderlife also seems to generate 1 big css. With falcro-css it's in clj & cljs. Gets dead code eliminated, and with code splitting you can bundle js & css.
@claudiu You know, I hadnāt actually thought of the dead-code elimination part. I suppose in the CLJS side, since nothing was calling the static methods for getting the styles, then theyād be eliminated. Is that so?
yep. They have to compose to the top. If you don't use it it will not get bundled in production. Also like the idea of loading in the html only the css needed for that page.
And by loading only the CSS for that page, youre referring to the new code splitting stuff for cljs?
@levitanong nope š I mean that if I'm on the about page I can load only the layout & about page css into the html (the other css is in the js but I don't add it to the dom). Then when you change the route, unmount the loaded css and insert the css for the other page.
like this one: https://demo.reactstarter.com/
in chrome inspect the header and then change routes, and look at how the css is loaded on route change š
@claudiu interesting
@roklenarcic Ahā¦I forgot to recompile the js file for the live guide with the new naming. Thanks!
should be working now
Hi, I am stuck with this issue: when my component is a root component the parser calls the read function before rendering. When my component is a child of another simple component, the read function does not get called by the parse and the component is rendered without any data. Is this an issue with my query expression? Is there away to trace the execution?
hello @marvin, you mean render after a transaction? or on first render?
Hi @wilkerlucio on first render the parser does not call my read function if my component is not a root component.
@marvin are you composing the queries on your root component? remember that with stock Om is your responsability to parse the query, so you will only receive reads directly for the root entries
the critical thing for me to grok the query business was to realize the render fn isn't considered while creating the UI query
so rendered children's queries aren't implicitly included in the final query
( at least to my knowledge )
@samcf yes, that's true, and that's what enables the query to be fully realized in a static way
@wilkerlucio so Om only call read for the root component? Do I then need to pass down the data to the child-component at rendering time?
@marvin yes, your root component is supposed to have the full query (composed by calling om/get-query
on the children), and then on the render you pick that value from the props and pass down to the children
can you share with us how is your root component is written? I guess we can get less abstract and see what might be wrong
@marvin There is a path-opt option that allows Om to start at a component with an ident
but initial render will always come from root
@wilkerlucio my app data is a simple big map and my queries are simple keys. My app has one root component for menus and to implement routing using Compassus. The next level of children components display a mixture of text and clojure code in a text editor, these components uses a simple key to retrieve the code from the app-state. Your explanation helps to clarify the fact that the parser only invokes the read function for root component and it is the responsibility of the root component to propagate the data down to its children components. I did not know this fact and was assuming something else.
@tony.kay hi Tony, thanks for your input, I was not aware of this option.
@marvin in case you don't know, there is a helper function called om/db->tree
that does most of the effort to translate from a DB form to a plain tree, but maybe it's not much helpful if you are not using idents
Iāve had some recent problems with path-optā¦possibly only with unions. not sure. There is an open issue on it.
and idents: you should be using those š
@wilkerlucio I will explore om/db->tree. I have not thought of using idents since I don't have list of data to display. @tony.kay Do you meant I should make a practice to use idents across the board?
@wilkerlucio after a transaction, is it correct to assume that the parser will invoke the read function only for the affected components?
@samcf Thanks for your clarifications.
@marvin it will trigger the re-render of the current component (if it has an ident, hehe), otherwise you should add follow-up read keys for the keys affected by your transaction, eg: (om/transact! this '[(my/tx {}) :affected-key/to-be-read])
but I think this behavior also depends on the path-opt
setting
@tony.kay can you clarify that one? I'm not sure if after a TX the root query is called when path-opt
is off
@marvin Idents are what make mutations easy. It causes all component to appear in ātablesā, which make get-in, update-in, and assoc-in able to work with them using the ident (two element vector). So, anything that changes over time should have an ident.
The query (wihtout path-opt) is always from root; however, it gets focused to the components that need refresh
focusing is this cool function that strips off all of the query branches that donāt lead to the component(s) of interest
so, your query is much lighter on a refresh
but it is still structured from root (unless path-opt)
with path-opt, it is basically hooked up with a join on the componentās ident [{[:table id] (om/get-query component)}]
so that the query can start from thereā¦but since the parser needs to be told how to handle that, it is not on by default.
@tony.kay This is great stuff, Thanks for your detailed clarifications. I will make a practice to use idents. I can't seem to be able to locate references for path-opt
and focusing
from Om-next's documentation. Do you know if there is any documentation on these? Thanks
@wilkerlucio Thanks for your response. It was very helpful.
@marvin. path-opt is undocumented. I wasnāt even sure it was still supported (from 2 yrs ago, almost). Was told that it is.
Focusing is an internal detail, not of importance to the app writer. It is an optimization. Read the source: next.cljc focus-query
I think
@tony.kay Thanks Tony. I feel the need to dive into the Om-next's source code and swim like crazy.š
@marvin no problem š
@marvin one extra tip, it's great to learn how Om.next works, but if you just want to make an app, I recommend checking https://fulcrologic.github.io/fulcro/ written by @tony.kay, it already implements most of the basics that you need to write an app, also it has very good introduction videos that you can learn from (and they are made in format to beginners, so you don't have to learn Om.next before hand to learn Fulcro)
@wilkerlucio Thanks for the tip I will definitely look into fulcro
i'm trying to upgrade the version of Om I'm using in an older codebase. It does not use any Next features, but I understand that om.div and om.core should be the same in the current Om version. All I do is require these two namespace in the code. I removed the explicit loading of react.js as was necessary long time ago, but i'm getting error
dom.cljs:54 Uncaught ReferenceError: ReactDOM is not defined
when i try to run the app after this upgrade.i also get
Uncaught TypeError: Cannot read property 'ReactComponentTreeHook' of undefined
in the react-dom.inc.js