-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Use transitions without removing the element from the DOM #6336
Comments
An alternative here to what you suggested would be a new construct called |
I'm trying to create a fork with your solution... Edit: So, Implementing your solution would require a lot of code that checks reactively when transition values change with invalidation and other things like that from other parts of svelte. Is there something I'm misunderstanding? |
Hi, thanks for your interest in the issue. I see. The only dynamic property is
Could this be relatively easy to make the transition module subscribe to changes of the visible property and allow to change visibility while the transition is in progress? |
@mckravchyk Sorry About my delayed reply I get way too many things in my inbox. I think that using a store might work |
I'm in favor of this too, needed this a few times myself, opted for direct CSS animations instead. |
Hello, I'm trying to implement a solution to this problem, but I'm not sure of the most appropriate syntax. I don't think adding parameters to the transition is the most appropriate for some reasons (transitions are not reactive, and the params are passed to the transition method, with the risk of conflict) But as alternative I don't know if I should opt for a block (ex {#display}) which would include the element(s), or for a directive on the element itself (ex: svelte:display). {#display} block :Basically it's the same syntax as an {#if} or {#key}, except that the elements are not removed from the DOM.
By default it will add a {svelte:display} directive :Or we can use a simple directive :
We can use an objet to specify the class-names : What do you think ? |
Hi! Thanks for giving this a shot! I think the latter approach with the display directive feels more natural - using a block would be cumbersome. I really like the idea with using class names by the way, that sounds like an obvious approach, but I missed it. |
I coded a basic prototype (only with display:none for now) and submitted a PR. |
Is your feature request related to a problem? Please describe.
It seems like Svelte transitions require that the element be removed from the dom when it fades out and re-attached when it fades in.
I guess it's probably fine if the element is very simple, but usually, it's not. For example, whenever I just want to show/hide a complex sidebar menu, the dom contents of that menu have to be recreated every time it's displayed (and some other stuff like event listeners, js logic has to re-run, etc.).
Describe the solution you'd like
Extending Svelte transition API to allow to fade an element in/out of view without removing/re-attaching it. So for example, instead of removing the element, set a
display: none;
style, or control the zIndex. (The latter would also be very nice, while we are at it, as in some extreme scenarios it's better performance if the element is already visible).The ideal, most universal solution would be to let the user decide what should happen to the element on transitionStart / transitionEnd and allow that the element to stay without being removed.
So for example, this is how it's done now - the element will be removed:
This is how it could look like with controlling the display property - which would be done by supplying
visible
property to transition properties:Advanced usage: define the way in which the element should be shown/hidden.
Describe alternatives you've considered
Doing it manually, perhaps Svelte animations API could help (I haven't gotten to it yet).
How important is this feature to you?
Of medium importance. It means that I cannot use Svelte transitions API (which seems awesome). It also seems to be one of those rare cases where Svelte could use some performance optimization.
The text was updated successfully, but these errors were encountered: