Sortable inputs are not focusable about solid-dnd HOT 7 CLOSED

Got you, missed that part, you are right, it works with on:pointerdown

from solid-dnd.

FYI @yonathan06 - I've released 0.4.1 now with the fix to not intercept input focus by default. I think you will likely still be better off with the drag handle for your case, but thanks for inspiring this improvement to the library.

from solid-dnd.

Yeah, we call event.preventDefault in the sensor activator (pointerdown event) which would have the side effect of preventing focus on the input.

We did this to try and prevent confusing behaviour, but I guess we could make it configurable when setting up the sensor.

Another approach would be to not make the input itself directly draggable, but make a drag handle for it.

Although, looking at your example I'm surprised the event is intercepted by the parent which the handler is on and the input doesn't receive it. 🤔 Might have to take a closer look when back at my laptop.

from solid-dnd.

If I remove the event.preventDefault call then we end up with a poor experience as dragging the object around causes things like text selection on the page. But we could potentially address that by intercepting those events after the drag has actually activated.

I'll have a look into that as a general improvement here.

However, a drag handle approach might be a better solution for you as you would still end up with potentially confusing behaviour in some cases -> someone trying to drag select text in the input would actually start dragging the input. I added a drag handle example to https://solid-dnd.com/#examples if it helps.

from solid-dnd.

Oh, and if you don't actually need the input to contribute to the drag activation (and still be focusable etc) you can intercept the pointerdown event and stop it propagating from the input.

<li use:sortable>
  <input type="text" on:pointerdown={(event) => event.stopPropagation()} />
</li>

from solid-dnd.

Thank you @martinpengellyphillips for the detailed response.
stopPropagation didn't do the trick, but adding an explicit drag handler following your example (instead of having the whole element draggable) works :)
Can see here: https://stackblitz.com/edit/solid-vite-zwawhq?file=src%2Findex.tsx

Maybe it is worth mentioning it in the docs? to use a specific drag handler when has nested inputs?

it looks like createEffect is not triggered when the store changes. Not sure if the DND causes it or something else, need to check

from solid-dnd.

No problem - glad you got to a solution.

I'm curious why stopPropagation didn't work for you though - I made the same change in your example and it worked for me:
https://stackblitz.com/edit/solid-vite-yaf9nn?file=src/index.tsx

Note that you need to do on:pointerdown rather than onpointerdown (see the :). This is because the use: directive has to set up non-delegated event handlers whereas Solid uses delegated event handlers by default.

from solid-dnd.