Fork me on GitHub
#fulcro
<
2017-10-31
>
baptiste-from-paris12:10:27

hello friends, I have a question about forms in Fulcro I am looking at the code and I see that DBAdapter protocol is not used. Can someone tell me what is the typical use case for implementing it ?

(defprotocol DBAdapter
  (commit! [this params]
    "Entry point for creating (& executing) a transaction,
     given params with the same shape as what diff-form returns.
     Example code for using `DBAdapter/commit!`:
     (defmethod your-mutate `forms/commit-to-entity [env k params]
       (commit! (:adapter env) params))")
  (transact! [this tx] "Execute a transaction!")
  (gen-tempid [this] "Generates a db tempid.")
  (parse-tx [this tx-type data]
    "Given a tx-type and data, transforms it into a db transaction.
     OR TODO: Should this be add-tx, set-tx, etc..."))

vinnyataide17:10:50

Hello! noob question. How can I insert ui/react-key after def'ing the new new-fulcro-client? when I log (om/props this) on the Root it shows

{:navbar {:route Menu 1}, :ui/locale :en}

tony.kay17:10:11

@baptiste-from-paris Hi, that protocol was intended to be the base for a pluggable form processing system. It is probably not going to materialize that way, because custom mutations with form deltas just make more sense in general.

tony.kay17:10:45

@vinnyataide props will only contain what you’ve queried for…is it in your query?

tony.kay17:10:00

and not sure how that relates to creating the client 🙂

vinnyataide17:10:13

I thought new-fulcro-client would create the key after every refresh ;x as I said I'm noob.

tony.kay17:10:24

mount updates the key

tony.kay17:10:37

new should only be called once, or you’re rebuilding a whole new client

tony.kay17:10:55

you point figwheel at a function that calls mount on code refresh

vinnyataide17:10:56

In the tutorial there's no query in the root and it is asking the ui/react-key on props

tony.kay17:10:05

then the tutorial is wrong

tony.kay17:10:14

pls point out the code in question and I’ll fix it

tony.kay17:10:00

oh, this is before adding queries at all

vinnyataide17:10:46

Yeah, I had to go back to no queries since when I put :ui/react-key on my query it doesn't get it

tony.kay17:10:03

that should work. The chain of ops is: 1. Project file: specifies :on-jsload and :main 2. user.cljs has a refresh function that remounts

tony.kay17:10:16

so with no queries it works?

vinnyataide17:10:31

no, I just said that I came back, and still doesn't work

tony.kay17:10:43

check the two things above

tony.kay17:10:46

for spelling etc

tony.kay17:10:59

on first mount react-key might not be there, but on remount it should appear

vinnyataide17:10:30

I'm using boot-cljs with reload (reload :on-jsload 'om-learn.app/refresh)

vinnyataide17:10:52

the main file is specified in the edn

tony.kay17:10:25

Ah…if you’re using boot, then you have to figure it out. The example, as written, worked when I wrote it

vinnyataide17:10:39

I'll ask on the correct channel

tony.kay17:10:15

I know more than one person that has ported back to lein from boot due to issues in general…it sounds like a good idea, but in practice it has a lot of problems, esp in larger projects. Others on the channel might have some input that confirms or varies.

tony.kay17:10:49

The only trick is to get mount to happen again after hot code reload. That should be it.

tony.kay17:10:03

so if you’re logging refresh and it is re-mounting, then it should refresh

vinnyataide17:10:49

ok the fn is not being called, it logged only once... thanks for the clue

fatihict17:10:28

We switched from Boot to Leiningen. For the most parts it works great, but I ran into trouble with Java loggers and Boot and some other issues I can't recall at the moment. Also I see a lot more examples with Leiningen compared to Boot which also helped with the decision to go back to Leiningen.

vinnyataide17:10:18

thanks @fatihict I'm using it since it's easier for me to understand, but lein is fine.

fatihict17:10:44

@vinnyataide Boot is also really cool, but if you're just starting with Fulcro or Clojure(script) in general I would recommend using Leiningen. You can steal a lot of code from the fulcro-template here: https://github.com/fulcrologic/fulcro-template to get going 🙂

vinnyataide19:10:36

sorry for offtopicness again but you guys are aware of my context. I've changed to figwheel, and now I'm missing one thing. my dev server was fullstack with a component system-map. Can i use figwheel as a plugin inside my dev-server which renders server-side?

claudiu20:10:00

@vinnyataide For server reload with component system-map. You can take a look at the flow from https://github.com/fulcrologic/fulcro-template . Figwheel is client side only, the template has the setup so that you just run (restart) to reload the server .

claudiu20:10:48

you're welcome 🙂

tony.kay22:10:45

So, I’ve finished evaluating the pros/cons of dropping Om Next as the back-end library: Fulcro 2.0 will include the conceptual framework of Om Next and some of it’s code, be API-compatible with 99% of Fulcro apps (with the 1% being easily fixable with a sed script), but will no longer be an adapter on top of that library. This will allow me to better maintain and support the community, and will allow me to fix some issues that are blocking progress that I’d like to make with the library. The new dynamic query engine I’ve prototyped (already working on 2.0 branch) fixes the following problems already: 1. SSR with REST-based routes in the presences of dynamic queries is now possible 2. Dynamic queries work with support viewer (serializable) 3. Dynamic queries are much easier to reason about locally and globally, and are not lost for spurious reasons like component remounts on locale changes 4. The underlying reconcile is much more efficient. I expect to see at least 2x better query engine performance (path-meta is no longer needed, and it is as expensive as db->tree). 5. I can optimize db->tree and possibly triple its speed (unverified, but with transients I expect that kind of improvement is possible) 6. Path opt can become the primary UI refresh option, as opposed to an opt-in optimization that has a strange bug 7. Much of the internal code complexity evaporates (Om Next’s tracking of dynamic queries accounted for almost all of the hard to read/understand code) 8. I can control the rate of PR acceptance and bug fixes at a much faster rate than we’ve seen with Om Next 9. We can eliminate the complexity of feeling like you have to understand two things. Fulcro is its own thing, the docs will become much clearer

tony.kay22:10:38

I’m not done yet, but in just 12 hours of work I’ve gotten the vast majority of it simplified and working. I’ve got a lot of other things going on, but it isn’t very much more work to get the rest of it polished.

tony.kay22:10:30

The possible down-side is that without data path information I’ll have to augment the internal time-based refresh, and all components will need an ident or risk from-root rendering. This seems an acceptable cost for all of the benefits, especially since it doesn’t make much sense for a component to not have an ident.

claudiu07:11:21

@U0CKQ19AQ Currently I'm doing something a bit strange, not sure it's the best pattern, for reuse. https://gist.github.com/claudiuapetrei/9724b5937790d3ed955f5db4468473b8

claudiu07:11:59

Basically I have a base component that has a query & no-ident, + css. The wrapper component gets that query and adds the extra fields it needs. Would this cause problems in the fulcro v2 ?

tony.kay15:11:47

Looking…

tony.kay15:11:43

So, this is kind-of an anti-pattern. Not sure of your intention with the term “wrapper component”. If you’re trying to do composition, get out of OO head-space, and just def stuff…e.g. (def base-query [:id :title :authors_str]) and use that. Don’t enclose it in a defui and pretend to simulate inheritance.

tony.kay16:11:12

I guess you’re doing that because you want to bring in CSS rules?

tony.kay16:11:00

So, it’s cool to use defui to define CSS, but the query stuff is special, and is never meant to cross component boundaries. Technically, the way you’re doing it will work (i.e. won’t complain or break if all you ever render is the wrapped stuff), and the concat/into circumvents the protection warnings…but, it advertises a pattern to other future devs that could make them think certain uses like this are valid that are not. So, it is more of a self-documenting problem than an actual bug.

tony.kay16:11:14

Short answer: Anything like this will work identically in 2.0 as it does now.