how do you show docs for a symbol (like you do for defcard-fulcro in your second video tutorial) in cursive/intellij?

omg I just found it

F2 I think…me personally, I use IdeaVIM, and it is SHIFT-K (in command mode)

oh, cool... ok, I hadn't found shift-k and that works well.

I use ideavim so right on.

yeah, that is the normal vim shortcut for “looking up” something under the cursor

like in a dictionary

I really don't know how you were able to create so much supporting information for fulcro.

I have absolutely no excuse for not succeeding with this framework.

😄 It has taken years

and a lot of refinement…and I’m still super critical of it

I think it still sucks 😜 But at some point you have to say “good enough” and get other stuff done

ah ok... well, it's kinda mindblowing... like video tutorials? check. maybe you prefer a github readme... check. or a book? check. and so on and so on.

the book covers about half of what I could say

2 dozen more vids would be nice

but its a start 🙂

yeah, videos are great.

at the same time, I feel like I need to improve my own skill at reading docs.

with text docs, I tend to go down rabbit holes of my own finding.

active reading….do while you read…don’t just read

yeah, but that’s good

videos are like park rides... you have to keep moving along.

just learn to focus the rabbit hole energy to a limited step

I'll work on it. ;-D

Hi all, is it possible somehow to inherit/share code between defsc components? Let’s say I have one complex entity with a lot of fields and I need two different ways of displaying it. If I create two independent defsc components, there’s going to be a lot of code duplication: args if I use destructuring, query, ident, initial-state, that’s going to be the same. The only difference is going to be the render code. Can I somehow avoid the code duplication? The only partial solution I see is to do (prim/get-query TheOtherVariant) in one of the variants, but that feels ugly and I think it can not be used to share args destructuring…

You can use regular vars or functions for the query, ident, initial-state. It's not really inheritance but probably the easiest solution

@johnny Yes, that’s what I meant, but that does not help with tens of fields I have to list in args destructuring.

@bbktsk so, it shounds like you're wanting to render the same entity, but with different viewpoints?

how about this: write it once, and use a computed prop through a factory to choose the UI?

(defsc Person [this {:keys [person/name person/age person/spouse] :as props} {:keys [renderer] :as computed]
  ...
  (case renderer
    :view (render-person-view name age)
    :detail (render-person-detail props)
     ...))

(defn ui-person-view [props] ((prim/factory Person) (prim/computed {:renderer :view})))
(defn ui-person-detail [props] ((prim/factory Person) (prim/computed {:renderer :detail})))

@tony.kay yes. Aha! That makes sense and it’s exactly what I needed! Thanks!

If you need to use other computed data, of course you'll have to read/write that to propagate it in the factory

should add that to the book ...

Well, still need to repeast destructuring for args, but apart from that its pretty elegant.

why?

your render functions could take any number of args

oooooh. Right!

I've been trying out fulcro-sql to see if it fits my use-case. But I've found a few issues with it. Do you accept pullrequests on that repo, because in the process of debugging I manage to fix said issues.

absolutely...not enough tiem to maintain everything myself 🙂

Can imagine, cool. It will probably find your way over the weekend

k, thanks

any doc fixes are great too...I know there are some errors in that repo

Can't promise that 😛 English isn't my first language and not a great writer to begin with

But i'll see what I can do either way

no expectations 🙂 Just if you noticed anything technical. For a while it had an old way of making the components that didn't even work anymore.

I just forgot to update the docs when I changed it

There is also one glaring missing feature: queries of data on join tables. I know what I want to do for that, but won't be allocating time to do it anytime soon.

so, if you end up with time and need it, I'd be glad to sketch out what I'm thinking would work, and help someone understand how to put it into place

Yeah that's something I need aswell

What I could use aswell, is some kind of post processing of attributes after it's fetched from the database

yes, that is the other one: data coercion...had a discussion with someone on that recently...who was it???

Haven't read that iam afraid

might have been PM

so yeah, more knobs are needed for sure, and I'm happy to get PRs to add them. For new features, I'd want to collaborate on them....so let me know when/if you have time

new API always comes out better when more than one person designs them

Oh definitely

For data coercion a simple item in schema ::core/coercion. With key attribute and simple coercion function, might suffice

Probably speaking to fast, because you need it two ways

That’s why I’d prefer not to do it in isolation. just the research on what is out there takes time

I’d prefer to leave a flex point if possible for that kind of thing. Make it pluggable.