Funky interaction with fokus management
TJS's Focus Management is creating fun issues for me again. focusKeep = true causes my drag and drop sortable list to break (@jhubbardsf/svelte-sortablejs) but focusKeep = false causes my dropdown menu component to break (svelte-select). I have now defaulted to focusAuto = false because I do not have the energy to fix either of them on my own right now. I think having at least a foundry-ish dropdown menu might be a fun idea for a svelte-standard component though.
5 Replies
Yeah... Focus management with 3rd party components is challenging if those components are not designed in a modern way using pointer events. IE components designed with mouse events may not play nicely with the focus management. On a cursory review of
svelte-sortablejs it is a wrapper around sortablejs. It is not immediately clear if sortablejs is using pointer events. It does appear to use them and the default option supportPointer should be set to true (on non-Safari browsers; seems an old workaround for Safari -13.x is still in place). svelte-sortablejs doesn't expose all of the options of sortablejs, so manually setting supportPointer doesn't appear possible.
Turning off focus management via focusAuto: false is a reasonable workaround for now in your case. The core Foundry App v1 infrastructure doesn't do focus management of any kind. I doubt the App v2 API will do it as well, but we'll see. I am baking in good a11y support / keyboard navigation to TRL.
Another possibility is the wrapping component say a mod to svelte-sortablejs that captures pointer events and is generally aware of a11y focus traversal.
The general good news is that I'll be addressing an official way to support drag and drop + sorting in the Oct-Dec dev push.
I think having at least a foundry-ish dropdown menu might be a fun idea for a svelte-standard component thoughYou'll have to let me know what a "foundry-ish" select component might be. There is
TJSSelect in the standard library which is a normal select component without all of the fancy options of svelte-select.I'm looking forward to the next few updates then!
As for the Select Dropdown. Most premade select components are very opinionated in their design and restyling them to look native to foundry is a pain I am simply not ready to commit to.
The two features I am actually using them for is searching the dropdown list and custom entries.
TJSSelect / basic select will look like the Foundry styling by default, but can be data oriented / store control + most of the components I'm making can take a special set of
efx actions where you can do some fancy effects. Right now I just have the Material Design ripple effect, but you can compose your own and even define an animation w/ WAAPI. https://typhonjs-fvtt-lib.github.io/api-docs/modules/_runtime_svelte_action_animate.html
No searching / custom entries with it though. I'm definitely keen on flushing out the standard library with a full catalog of advanced components that all work well together, so a more advanced select component will be there eventually. A lot of other work comes ahead of that though such as getting things running on top of SvelteKit / Svelte in general while maintaining Foundry support and converting everything to Svelte 5 when that drops, so the standard library will still be a bit thin for a while. The goal is to make it so the need for additional 3rd party components is on the more rare side of things.Is Svelte 5 going to be a big change in how it works?
Yes, insofar that the "old way" will likely be removed in Svelte 7 and Svelte 6 will cause deprecation warnings or at least that is what I've been able to gather from snippets of discussion on the massive
svelte-5-runes channel on the Svelte server. You can get a gist of the "old way" from this list: https://svelte.dev/blog/runes#simpler-times-ahead. In the interim things don't need to change for Svelte 5, but I'm going to jump on it sooner than later for all TRL components. I'll do a 0.2.x release of TRL when it requires Svelte 5. So kind of like a Foundry upgrade situation. I'm not sure yet if the "new way" will add significant capability to better handle some of the challenging aspects for finishing reactivity re: deep integration w/ the Foundry document model; it might or has some chance of doing things in a different way that will work better than stores for the use case.
Being that I'm aiming TRL to be a 1st class citizen in Svelte I'll be switching all of the aspects over that need changing once Svelte 5 drops which is expected generally before the end of the year. I probably won't create too many more components until then as well. There is a bunch of work to generalize the TRL architecture as well while still keeping Foundry compatibility; the API restructuring that was released w/ the 0.1.x series sets all of that up. TRL is in a unique position of abstracting things and defining a standalone replacement for some of the core Foundry API aspects that are currently leveraged directly from the Application API; of course App v2 hangs on the precipice as well, so we'll see what that brings...
With the above while TRL will update to the latest Svelte idioms it is not required that everyone using TRL has to do the same thing in the same timeframe. You can still keep using the "old way" for Svelte 5 & 6 apparently in your own software / components built w/ Svelte; eventually an upgrade will need to occur though likely by Svelte 7 whenever that may come out. It does look like there will be a bit of ongoing work on Svelte though so at a random guess; by the end of next year, etc.