@roklenarcic when you have multiple components with same ident but different fields, how do you solve that? Is there a way to alias each one like in graphql?

i suppose with the DB tables, you want all the records in one lookup table, right? but if they have different fields, then do the records in the DB have different sets of fields too?

@wilkerlucio @gardnervickers Did either of you submit a bug report? That’s a pretty nefarious little thing

@thosmos So, the server-side state has to be constructed to match the state you want the client to be in….but it’s so crazy cool simple: InitiaAppState (cljs = clj!!!) means you can get the initial state for your app as a tree, just like the client-side does. Then, you can use the same optimistic update code (again because you can use cljc for it) to mutate the app into the correct state.

InitialState -> login mutations -> routing mutations -> drop some server-side stuff that would have been loaded in -> state as the app would be on the client.

(defn do-that-thing* [state args]
  (-> state-map
      (assoc-in [:table id] :blarg args)))

(defmutation do-that-thing [params]
  (action [{:keys [state]}]
    (swap! state do-that-thing* params)))

now you can use do-that-thing* in other mutations (when you need to compose things on the client side), and you can use it to evolve server-side state for SSR…

The one complication on the server is that union initialization for InitialAppState has to be involved, and you’ll see there’s a helper for building initial state so that you get that right (to-one unions initialized via a tree (of InitialAppState) only have one branch in the tree…so it is the only one that gets normalized in during that first tree->db…but the helper fixes that by scanning the query and components).

@roklenarcic @thosmos With regard to same ident/different fields: I assume you’ve got that because they are the same entity, but different UI components want to see different parts of it. If you’re doing anything else, then I’d consider it a design flaw. You should carefully read the Developer’s Guide on Data Merge (subsection Deep Merge) in section H Server Interaction.

Same ident should = same exact conceptual (or persistent) entity

more than on UI component having the same ident just means different views of the same thing (PersonDetail, PersonView, PersonForm, …)

remember that Ident is how auto-normalization works. If you give to things the same ident, then you’ve just indicated to Fulcro to put them in the same database table entry (table and ID). You wouldn’t do that in an SQL database if they weren’t the same thing, would you?

@wilkerlucio 🔥 Just pushed the first working mutation join auto-merge demo (in 2.0)!!! The mutation-join-cards (requires you also run the demo server). Note line 12 (remote only mutation) and 18 (a mutation join with query). Clicking the item causes the server to reflect back the return value of the mutation as the tree to merge. So cool. Thanks for the suggestion!

https://github.com/fulcrologic/fulcro/blob/2.0/src/demos/cards/mutation_join_cards.cljs#L18

Can anyone suggest how I can add a js react component to my fulcro project? For example, how can I add one of these data tables to a devcard? https://react-table.js.org/

if I run 'yarn add react-table' from the project root directory, will it put things in the right place?

@dfornika Haven't played it js modules, it's on the todolist. From what I know it's not that strait foreword. Fulcro has a semantic-ui wrapper, might have what you're looking for.

https://github.com/fulcrologic/semantic-ui-wrapper

also worth looking at: http://cljsjs.github.io/

devcard example here https://github.com/fulcrologic/semantic-ui-wrapper/blob/develop/src/cards/fulcrologic/cards.cljs

@dfornika regular React components work fine. This is more of a foreign lib question. See cljsjs and the latest blog posts about using node modules with clojurescript. The links @claudiu sent are relevant for calling them from cljs once you get them working. See also shadow cljs

See the STEP comments within. This particular project file pulls in blueprintjs, which does seem to work. Others I’ve tried have not worked…so it depends on the lib in question.

@tony.kay @claudiu Thanks for the tips. I'm just getting started. I've been wanting to try om.next for a long time but could never quite get off the ground.

well, I think you’ll find Fulcro to be easier.You still have to learn the new concepts, but there is much less fiddling to get something real working.

https://github.com/awkay/node-trial

is a github version of the blueprintjs thing…I don’t remember what state I left it in, but it did work at one time 🙂

I have limited battery at the moment, so I don’t have the power to spare to check it

Does anyone have a recommendation on the easiest 'data table' component to get started with? I'd just like to load some data into a table with a few features like sorting, filtering and pagination.

I would recommend getting started with much simple things

Get used to the ideas…if you jump right into something where you have to integrate external components and debug all of that you’re just going to get overwhelmed

Ok, good advice. I'll spend more time with the intro devcards.

First things I’d recommend would be any of these: GettingStarted.adoc in fulcro repo The YouTube videos The Fulcro DevGuide…at least through the server interactions section

All three are tuned for the beginner to start

The older Untangled videos on YouTube are also useful, including the whiteboard discussion about loading theory. Just replace the word Untangled with Fulcro everywhere you hear it 🙂

Fulcro 2.0.0-SNAPSHOT updated. In the past two days I’ve added: - Support for mutation joins (mutations that act as a join key, and indicate an auto-mergeable return value from a mutation) - Support for declaring refresh lists on client mutations (eliminates the need for UI follow-on reads) See the mutation-join-cards and declarative-mutation-refresh in demos for sample code.

@wilkerlucio Those sugar helpers are also now present (`returning` and with-params)….so a mutation can now look like this:

(defmutation change-label [{:keys [db/id]}]
  (remote [{:keys [ast state]}]
    (-> ast
      (m/returning state Item)
      (m/with-params {:db/id id}))))

Then in the ui one need simply say:

(transact! this `[(change-label {:db/id 1)])

and the server can return whatever tree of data makes up Item and it will auto-merge!

Of course, you can always hand-code the mutation join at the UI-level…but it looks messy

nice! 🙂

actuallly…my network (hot spotting from my phone) is crappy…snapshot still updating

now it’s done

do you think it's a good time to start trying migration? or still too soon?

I’d love early adopters to start trying it. I’m sure there are going to be bugs…but the sooner people start trying it, the sooner we’ll fix em

I’ve been hammering a lot on cleaning up some internals as well. I eliminated the plumbing namespace, rewrote the mark/sweep algorithm for data merge. I was pretty well covered by tests on some things, but others like integration behaviors are just really hard to catch.

I’d also like to know if any existing larger apps see any performance differences. I suspect since path-opt style rendering is the default it should be faster. There are some cases where I force a root render more aggressively, but the React/shouldComponentUpdate optimizations should make those not noticeable

Fortunately, porting should mainly just be the scripted steps the README-fulcro.2.0 doc

unless you were depending on some internal functions I’ve removed…in which case I want to know what you were using

The new support viewer is written, but untested…got sidetracked

I'm planning on writing some helper tools over this weekend

I want to make something like re-trace to fulcro

the dave conservatoire might take some effort to port, given it uses dynamic queries

did the interface for dynamic queries changed?

so, dynamic queries work a little differently, and you have to implement a different protocol (`dynamic-query`)

could be a good exercise, but I'll very busy with other things lately

basically, dynamic queries are functions of state and ui-factory now. Distinct UI factories give you the critical index

and they are strictly stored in state by class/ui-factory-qualifier. This makes history work properly, but does mean you have to add a little code to make them work how you want

Helper tools would be nice…you saw the issue with help wanted in Fulcro github?

looking at it now

my goal is to have something like this: https://github.com/Day8/re-frame-trace

that can have a nice view for mutations

and db watches, seems close to the issue things

and as an extra, I want a tab to have a history of network activity (queries/resposes)

You might read this: https://github.com/fulcrologic/fulcro/issues/52

yes, I was reading that

and the new history recording has a lot of what you’re looking for

It records what sends are sent at a step, and the list of active things in-flight updates over time as well

(as snapshots in time in the history steps)

To me, the table/entity viewer are really most important….well, being able to focus/see/run a component’s query would be nice too

anyway…gotta get some lunch. Have fun!

yeah, I guess OgE can get integrated if we want

could be nice