Fork me on GitHub

@jarvinenemil SSR does work, but the old template branch probably isn’t up-to-date. I think the basics are covered in the book…really isn’t much more to it than the dom-server macros can be used in CLJ-land to generate strings…you just need to pass the correct props tree to the root. Generating the props isn’t so hard, since you can write all logic in CLJC, and use the same code you used on the client to generate props on the server…there are a few helper functions that can build a db for you on the server based on component initial state, which is the most common case for an initial render; however, if you’re trying to implement SSR that shows some HTML5 routed link, then you might find that you’ve got a bit more work to do. The good news is that Fulcro will run headless in the JVM, so you can create a client with a loopback remote and essentially move it through states until you have what you want.


I do not consider headless Fulcro to be battle-hardened. I do not personally use it that way, and don’t know if anyone else in the community does. I have seen no bug reports, but that means very little, really.


The DOM stuff outputting strings does have tests around it, and should be pretty good…but it is also an aspect of the library that I do not currently use in any projects, so it has been low priority for me to beef it (or the docs) up any. Contributions welcome.


Is there a way to tell a load to not delete keys when the entity it pulls from the remote has fewer keys than where it’s loading it into? I’m using multiple comps with the same ident and different numbers of keys (summary and detail), but the one with fewer keys is causing the extra keys to get deleted when it loads. hmm I guess it’s complicated because it’s difficult to differentiate between a query using fewer keys vs the keys having been deleted on the server. Cache invalidation is one of the hard things of CS


You can use a component with the same ident but keys in its query that match what the remote is returning.


yes I’m using multiple comps with the same ident and different keys, but the one with fewer keys is causing the extra keys to get deleted when it loads


If matching then no deleting should happen. You can be using a different component for loading than the one that's on the screen.


ah that might be it


or I’m switching between two different comps with the same ident -> summary and detail. would that do it?


Have special loading only components, that don't even have a render.


The special loading component is just loading into app state. You don't really even have to think about what is on the screen.


yes I’m doing that also, but sometimes I just load summaries, and sometimes detail, but when I load summaries, those are erasing the detail i already loaded


Are you using the detail component to do the load? That would explain deletion.


I sometimes use the detail, sometimes the summary


Server would be saying 'I don't have what you asked for', so deletion would happen.


no it’s that the number of keys asked for is different, the server always has it


Don't use either (summary or detail). Use a special component just for the load, and you might have many of these 'load only' components.


so use a different comp for load than the comp for display?


and what if I sometimes want to load many keys, and sometimes only a few, and I don’t want the one that loads a few to erase the many?


Have many 'load-only' components, as many needed, each one matching exactly what the server returns.


I’ll give it a try


thanks that works


so I’m unclear now under what condition the fewer keys query will delete keys …


The server is designated as the source of truth. So if the client asks for a key and the server does not return that key, then it is assumed that the key has been deleted on the server, so it is also deleted on the client.


i see now that my problem was due to this


my comp was set to automatically load on mount and I was using it for a new client-side created entity, so it was erasing all of the new values


I assumed the cause was different than it was


oops, hehe, i didn’t realize if I deleted the message all the replies would stay …


thanks for all your help on my wild goose chase


Glad it is all working. Even thou it is a simple rule, takes experience to be able to work with it.


Yeah we want the replies to stay. This is useful for people.


yeah it’s been working great, I just didn’t analyze my problem right in the beginning


should’ve just edited my original post to be more clear for anyone tuning in


TBH I think the original message should also stay. Anything to help others. This is a common 'trap' that people fall into.


Yeah, now I know.


Thanks for the excellent answer @tony.kay


Hi, I've been watching the excellent videos by @tony.kay. I am able to use href for dynamic routing, but when I type the URL in, it returns 404. How can I intercept the URL before it gets to the server?


@hadilsabbagh18 you don’t, you have to make the server respond with the index page for all valid routes, and then once your app is loaded look at the URL and fix your application state


I’m having a strange problem with a couple of non-fulcro UI components not rendering until the next render cycle (using the keyframe2 renderer):

  (debug "RENDER DataEntryDate" DataEntryDate)
  (ui-datepicker {:selected DataEntryDate
                  :onChange #(when (inst? %)
                               (log/debug "date change" %)
                               (set-value! this :sitevisit/DataEntryDate %))}))
I’ve verified that the render debug statement reports the correct value should be getting handed to the datepicker, but it doesn’t get displayed until the next render-causing change


remember that rendering is predicated on shouldComponentUpdate, which looks for prop changes…if props don’t change: no render….otherwise kr2 renders everything


so it’s behaving as if the datepicker’s :shouldComponentUpdate is false, but then it’s true on the next round


oh interesting, I just switched it from using interop/react-input-factory back to interop/react-factory and now it’s working fine which makes sense because the component isn’t what react-input-factory is made for. not sure why I was using that in the first place


ah, yes…the input factory expects there to be a controlled value that is a string, and it caches it in component-local state…should only really be used for inputs that you type into