search

quasarframework / quasar

Quasar Framework - Build high-performance VueJS user interfaces in record time
https://quasar.dev
MIT License
25.76k stars 3.5k forks source link

[experimental feature] portal option with/for keep-alived components #6150

Closed ibrainventures closed 4 years ago

ibrainventures commented 4 years ago

as a spa developer, where often dialogs etc. are used for dynamic ui/ux elements one problem often happens is, that sending a keep-alived compontentto the portal - after hiding the portal - it is destroyed. When now "re-open" the dialog, the forms etc. are unkeeped / fresh.

this is no error or issue by quasar, it is - i think - the nature for handling this process.

after some investigation, i found a issue at the "offical" vue portal from linusBorg where someone didnt closed the portal rightly, so the component was still keep-alived. May this "issue" is a way for a solution?

i also find a - untested - global keep alive

https://github.com/humor-grad-school/vue-keep-alive-global

where somone caches the component instance(s).

the request for this feature is, to give a way for working with the really usefull vue keep-alive option also inside portaled components. (primary qdialogs, but also qtabs, qsplitter etc.).

the state of the component inside the "sleeping-portal" should look like this inactive comp:

grafik

that there are other ways around, like status management vuex, vuex-caches, display hide, ... i know, but this is always a bigger-workaround and leaving the "quasar-way".

(and vue-router-keep-alived routes are also working nicely with quasar, but only for clearly routed "router-view-pages")

It would a great benefit for the quasar fw, if the developer has a "out of the box" component "caching". thank you for reading this "experimantl idea".

pdanpdan commented 4 years ago

In my opinion the right way is model driven. So you should save the state as data and restore it as required. The only component that had problems before (with restoring model) was the input type file - but you can now use the QFile component.

ibrainventures commented 4 years ago

Hi @pdanpdan ,

thank you for looking and thinking over my feature request.

Sometimes we have some Situations, where the re-render / model "fresh" query is timeexpensive (timeline lists with x-pagination) or some entry situations with the video element for video playing / webrtc handling is not easy to re-render (playposition, connection loss).

Actually i am testing with some dialogs to inject those inside the q-layout with dynamic components controlled by some vuex-states:

grafik

All "quasar style / div / classes" are manually added and i have that component now nicely keep-alived.

grafik

I also tried to patch your quasar portal component with storing the vm id and "controll" the destroy effects. .. I started with that but i didnt ended, because of the upcoming vue 3 situation.

If you think that "feature request" is not possible / usefull you can close this comment .. or may later when the vue 3 re-work is comming that this "option" can be implemented.

pdanpdan commented 4 years ago

It's an interesting case, but I think we should let it for Vue 3. We'll have to refactor the portals anyway.

ibrainventures commented 4 years ago

great .. sounds like a plan ... and may we can add a prop (array) for window scroll positions (this "issue" is still happening, also on keep-alived components ... (not a quasar issue :-) ) ...