yep

I only see this briefly, after a hard reload of the page, which is expected. But I run my own dev build of the Fulcro inspect (few weeks old)

I’ve hit this as well. Re-install was the only fix.

Could also be another incompatible chrome extension I guess…but yeah, reinstall will usu fix problems like that. Also make sure your compile has the preload for installing inspect.

I've run into it when using Brave, but got it work using Chromium

In principle or reality? 😜

the intention is for all db back-ends to support to-many scalars like enums. Some of that is not yet implemented.

well, and in Datomic enums are technically refs, since enumerated values are technically entities with a named ident.

In reality 😅

Yeah, you’ll find it isn’t a lot of code, but there are two things to implement to get that to work right: 1. make sure save-form works with it in db adapter…I think it will. 2. Implement the UI rendering for it, which I’m pretty sure I have not done. I’ve not done rendering for any to-many scalars.

On the UI side, I think the layout for forms would have to be made aware of the to-many aspect…that might not be true…it might just be that the enumeration control renderer would have to be made aware. The resolvers on the back end would need to return a vector of values (which might need some adaptation in the resolvers).

basically every data type that isn’t a ref should support that, so it is a “turn the crank” sort of exercise.

I see... I might look into this when I actually need that functionality (might still be a bit, right now this project just needs to get off the ground). But on the database side? Will it correctly work in defattr as of today?

don’t remember to be honest

BUT

you can specify custom datomic schema stuff and that will merge last

::datomic/attribute-schema {:db/cardinality ...}

but I think that is done correctly just from ::attr/cardinality

Well, I guess I will find out when I try, then 😛

Also beware that I am making no API stability promises at the moment on RAD. I’m not changing it in major ways, but I am occasionally cleaning up keyword naming for consistency. I may still have to restructure the UI plugin data structure as well (and the rendering algs to go with it), but that should affect things minimally.

once I get the full picture realized I’ll stabilize the API and move out of alpha

Thanks, I realize it is in an early state. Might well be that I end up contributing some code, too.

that’s always my hope

I can do it by not letting go of the thread in the event handler. We’d still be using React’s component local setState, it’s just that we’d be using it synchronously, which is the way it does work.

I see. So I did misunderstand. I always got the impression React had moved or is moving entirely to async-only rendering.

not true…syncrhonous value would be obtained from state after transaction, so the derived value would be available

so that suggested solution would solve both

unfortunately I still see a cursor jump when calling setState with a derived value like:

setState({value: e.target.value.toUpperCase()});

Any non-matching updates coming from other transactions would update through :value, but that value would already match for the sync update

OH, right, that case…you’re right

:face_vomiting:

it’s worse, because the transformed value could change lengths

imagine a CC input that is adding hyphens

yeah

I've been grappling with a similar design problem involving contenteditable. Unfortunately what I'm coming up against is that cursor positions and selections are kind of an afterthought in the DOM API. 😞

I guess solving (1) cleanly and consistently with rapid UI refreshes fixes 95% of problems. If you do derived stuff, I can point out in dev guide that you’re in DOM land now…have fun!

yeah. unfortunately, it seems to be how the DOM works: https://codesandbox.io/s/m4r6myo5ny

localization makes it even harder…or we could just implement a frikkin DOM control in a canvas and be done with it

hahaha

yes, more yaks plz 😆

I mean, the ultimate problem statement is: we want to control the input, but it has mutable state that we don’t actually control…it gets mutated arbitrarily by the browser itself.

and if we say “no, we want this”, then we really are mutating the entire value…where else would you put the cursor in a mutable world?

Ah, that leads to the observation: maybe we need to treat cursor position as a “controlled” value at all times? Interesting…track keydown/keyup events, and synthesize our own change events?

that’s the way that people seem to be solving this in React land

Yeah, that is my conclusion with this contenteditable stuff as well

yeah. the more we talk about it, the more I agree…even though I hate it

if you are putting derived values into :value , then tracking the cursor position in state and updating it in useLayoutEffect seems to be the best practice

I think the sync transaction stuff for fulcro could be a nice performance enhancement, though. And that approach would also fix the weird async behaviors.

I would love it if there were a layer in React or on top of React providing a declarative API for setting cursor position. You'd still be in charge of computing what that position would be after a given transformation, but at least it would take care of all the Selection / Range nonsense

I think that’s pretty much what a hook would do

let [value, setValue] = useState("");
let inputRef = useRef(null);
let maintainCursor = useControlledCursor(inputRef);

function onChange(e) {
  setValue(e.target.value.toUpperCase());
  maintainCursor(e);
}

return <input value={value} onChange={onChange} />

it’s hard to generalize completely though because, like was pointed out before, you might have something like a CC which is going to change your length, and you want to handle that gracefully depending on the context

is it possible to get cursor position from the dom api? if so would it be possible at write time to read dom value (like Preact?) and cursor position and have a sync callback with these two args allowing decisions around that?

Yeah, what I'm imagining is a callback mechanism to make this fully generalizable. Something like:

:compute-cursor-position
(fn [e ref previous-pos]
  (if (something-special-happened)
    42
    (inc previous-pos)))

Well, I’ll play with adding the sync transact, and any of you that want to make a fork and contribute a concrete implementation of something I’m open to it.

I think Fulcro with sync transact would give us a real leg up over the competition, since it doesn’t have to “break the model” in either direction, and would also not need any crazy cursor management logic.

I got it…and it was way simpler than I could have hoped for! Fulcro already has props tunneling through setState! I’ve already got it working perfectly and fast with raw React DOM inputs.

You could use this, borrowed from Fulcro RAD

Add it to the list of ::p/plugins of your parser. Then :query-params is in the env of your resolver.

Right…that :params option of load adds EQL params to the top-level of the query, and that plugin will make the params generally available in the sub-resolvers. The nature of resolvers mean you should generally namespace your parameters and place them at the top like this because sub-resolvers may not be called if a top-level resolver can optimize the result in advance. That gives you the most back-end flexibility.