@wilkerlucio AH, your error on params. It works because it continues threading through that cond here: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/impl/data_fetch.cljc#L301 The validation check and the prior thing can probably be dropped…depending on how much we want ppl to be able to safely use the underlying load mutation directly

I’ll probably just remove the validation check. Could be some legacy use hanging around for the params placement

RC3-SNAPSHOT on clojars without that validation.

Datomic now has the ability to alias fields in pull statements, which Graphql also has. Any thoughts on implementing this in Fulcro?

@thosmos What, you mean internally in Fulcro’s query engine?

yes

purely theoretical question, I have no need for it personally

Not sure what the point would be, and it would add overhead, so I have no current plan. Don’t add things unless there is a compelling need. Anyone can add a local read routine to the engine with runtime options and make the query system do whatever.

Hi! I’m evaluating Fulcro for an application that would be fully client-side with a PouchDB storage layer. I’m tempted to (mis)use the remote comms for this, with a faux back-end that manages interaction with PouchDB running alongside the client in the browser. I’d appreciate an opinion on how much of an abomination this is, and perhaps a more idiomatic way to handle this (fit the PouchDB in the root node?)

@pmaes I think it is a perfectly valid use-case. You could also plug into the read-local system and provide a custom query parser that pulls data from alternate client dbs.

The local read story can be completely customized that way. The primary thing will be to hook in so that external changes to the database cause re-renders, but that’s easy.

Depends on if you want to feed the entire UI that way (where you’d have to store UI specific details in the external db). The remote option gives you better support for things like support viewer and such.

I’d probably lean towards the remote case. On incoming changes (from say a server), use things like merge! to push changes into the UI. If it is completely local, not sure why you need an external db at all…just adds more complications. The current db is trivially serializable for offline operation.

and the CQRS structure of the system makes sync’ing later also equally nice. Personally, I wouldn’t pull in PouchDB unless the point was to sync to couchdb.

@tony.kay The constraint is indeed to integrate with a couchdb system. I'd only use it to store and sync the business domain documents, with the regular Fulcro db still feeding the UI. It's this separation that led me to the idea of acting as if PouchDB is behind a remote. I'll have a look at read-local, it sounds as if that would be a cleaner solution should an actual remote enter the picture as well. Thanks for the elaborate response (on top of all the work you do)!

@pmaes See the ReferenceGuide.adoc in stale-docs in the main repo. There is a section on this…I just have not had time to update that doc.

line 2228

https://github.com/fulcrologic/fulcro/blob/develop/stale-docs/ReferenceGuide.adoc#using-advanced-parsing-on-the-client

so much documentation to update for 2.0…the getting started guide is next in my sights

@thosmos hey, I got curious by that, can you tell where I can read more about it?

ah, just found on the blog 🙂 http://blog.datomic.com/2017/12/datomic-pull-as.html

sound interesting, but at same time, thinking about adding this to fulcro story sounds like a hell of work prone to many issues