@sova Which om.next version are you on? There was one SSR fix that had to do with html-escaping the :style
map (css values).
React usually says exactly where the checksum missmatches. What does your error say?
Server-side rendering (with checksums getting picked up) has been fairly stable since September when Cellophane was merged in Om Next
AFAIK there have been like 2 or 3 fixes to SSR since then
is there a reference frontend/backend om.next app? something I could use to learn om.next?
ideally with SSR, backend api, etc
@mping you have todomvc by David Nolen if I remember well
@baptiste-from-paris is that for om.next? also dont think there is backend involved
yep there is
with a datomic
back-end
you also have some nice tutos by the untangled team
https://www.youtube.com/playlist?list=PLVi9lDx-4C_T_gsmBQ_2gztvk6h_Usw6R
it’s about untangled but it can help you understand om.next
Is there a "proper way" to deal with state that isn't in your app-state map in Om? I'm making a simple music player with Om.next and howler.js. To play/pause audio and so on I need to call methods on js objects. Right now I'm just calling them from action thunks in my mutate function but I don't know if there's a better way to do it since I guess you lose stuff like going back in history.
@emiluren Is there no way to make everything completely deterministic?
Here's a general question to the channel:
I have a :start
and :end
on my app-state that determines the time period for all reports and I have a problem getting the right follow-on reads to run, every time I change them.
All these reads are in the :reports/
namespace. Do you think it's a good idea to read the current root query, transform it to ast, extract all the :reports/
keys and add those as trailing reads to the transact which updates start/end?
@danielstockton I don't know. Maybe I could make some sort of data format that describes the state of an audio object and make sure it is in that state in my render function or something but it feels hacky and hard to get right
@emiluren render or other lifecycle methods. Anyway, I think that's what you'd have to do or else accept that some things are outside of deterministic history.
In order for you to retain proper history, you'd have to do this one way or another.
Ok, thank you for your help 🙂
The other way I can think to do this is to define all the report reads in one place, define which are acceptible for a given route, and then check the route before firing off requests in my parsers.
That might be simpler actually.
@mping same version of todomvc but with SSR https://github.com/anmonteiro/om-next-fullstack
@emiluren That actually sounds best and not hacky at all to me. I mean, you'll probably need to do a little fudging to make it work with an external object that's changing state in real time, so there may be some hacks there, but the approach in general sounds to me like the right application of React principles.
@anmonteiro We started using plomber for our dev build and would love to have it published at some point. Totally understandable if you don’t want to have to maintain that, just mentioning because I saw there’s a note about it in the README 😄
@gardnervickers 🙂 I just didn’t publish it because I thought nobody would use it
also the name was a stupid pun at the time
It’s proved very useful for tracking down problems where pathopt fails and triggers a root render.
oh wth, I even have docs for it
I don’t remember this being in such a good state
cutting a release now
Heh
Thanks!
I wonder how you found it though
I never really advertised Plomber 🙂
@anmonteiro I was looking through Compassus a while back and must have stumbled upon it somehow and it’s stuck in my brain 😄
Does the presence of a link in a query have an effect on if a component can utilize path optimization?