wip: feature/vue3-support #678
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#678
Loading…
Reference in New Issue
No description provided.
Delete Branch "dpschen:feature/vue3-support"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here you go ;)
feature/vue3-supportto wip: feature/vue3-supportf2f9deaff0
to2b30683e71
Oh wow! Impressing!
I've mostly pushed this in the future because it seems like a big, daunting task. And the best excuse was a) lack of plugins and b) no vue migration build (yet).
I guess this will show whether I caught all use cases with the test suite or not. Feel free to add new testcases as you see fit.
You'll probably be interested in these notes from the backlog task for the vue 3 migration (F-270):
Used Vue plugins and their vue 3 status:
Blocking
Working
What about linters?
@ -103,3 +104,1 @@
component: import('../../components/input/editor'),
loading: LoadingComponent,
error: ErrorComponent,
editor: defineAsyncComponent({
Is this still required with vite's async definition of chunks?
Since the editor is a quite large component I thought it might make sense to keep the splitting.
As far as I know every component using the editor will use the same chunk.
I did not check here but I guess this can be looked into at a state when analysing the chunks makes sense.
@ -65,3 +47,1 @@
error: ErrorComponent,
timeout: 60000,
})
const PasswordResetComponent = () => import('../views/user/PasswordReset')
How will error and loading states of async components be handled?
Good question. Maybe it makes sense to try out the new Suspense feature here.
Even better would be to reduce the size of the route chunks so much that there is not loading state. Maybe stuff like the editor is initially not interactive and will be loaded later, but the page navigation itself can be quick this way.
I think I read somewhere that vue-router preloads chunks from other linked routes on the current page.
Yeah I guess now is the time for vue3. I really love it. The composition api is awesome and the new sugar syntax for the setup function makes everything super clean.
For now I ignored all the tests :D . The reason was that everything breakes either way when you change so much at once. I will look into this after the big things are working again.
Regarding the packages:
I chose the easiest way with the packages and searched for vue 3 ports. Sometimes I found forks that make the packages work. Replacing the packages with better onces can happen in an future steps =)
I split updating the packages in individual commits, so be sure to check the commits instead of the complete merge. That makes the diff much easier to read.
I realized also I included some fuck ups when I rebased to main. I know that I mismerged some packages. I will force-push to update that later. This is also why I didn't link the SHAs here since they might still change.
Not sure
vue-smooth-dnd
This is not in the packages.json anymore? Did you remove it already?
Seems to be working
vuex
upgraded to v4
vue-router
Upgraded to v4
vue-i18n
Upgraded to v9. The migration guide is quite long. Might be that I missed something.
vue-shortkey -> vue3-shortkey
For the future one could use the
usemagickeys
function of @vueuse. Generally vueuse is a crazy good library that can be useful for lots of stuff.vue-notification -> @kyvg/vue3-notification
As you said: might make sense to remove that in the future
vue-advanced-cropper
Upgraded to 2.6
vue-flatpickr-component
Upgraded to 9
vue-drag-resize
EDIT: Upgraded to v2
Since the new version needs the composition api I didn't attack this yet. I think to remember that the old version work(ed)s with the compat build. So might be fine for now (needs check).verte -> replaced with native color picker
Instead of verte I used the native color picker. Might have some unsolved problems. I didn't test it on mobile.
For the future it might make sense to use some vanilla color picker library here. I tried initially huebee. Metafizzy the author behind writes really great vanilla libraries. This one sadly doesn't include an unmount function which makes it incompatible with modern js frameworks :/ .
I started implementing that but quickly gave up because I thought for the sake of porting to vue 3 the native color picker is fine enough. The reason I was looking at huebee instead of porting verte to vue 3 is that I thought that it might make sense to limit the color palette a bit so that contrast with text color etc. is always given. Huebee supports this really well.
If the user is allowed to choose any color there is no (easy) way to ensure this. Also it might look really colorful (nicely put).
vue-easymde
I copied the code and included it,
but there seem still some issues.Work needed
vuedraggable
This has support but the api changed a lot. There are still some problems here. I have the feeling the errors are related to vuex mutation violations. This was the original reason for the other pull-request (and what fucked up my rebasing).
2b30683e71
to839248e6c2
839248e6c2
toae551fc310
ae551fc310
toa5a3bc3dae
I haven't really used vue 3 yet other than in the usual hello world stuff but I agree it is quite nice.
Sure, I would do the same 🙂 As long as the tests pass in the end this is totally fine.
Yes, that's already removed. It was used for the kanban board but we're now using sortableJS (vuedraggable) for that.
I've never heard of vueuse but it looks really nice. I'm sure we can use some stuff of it.
I liked the overview of verte so I'm not sure how I feel about the native color picker but using one instead of verte should be fine for now.
I have thought about replacing the editor in the past as well as I'm not quite happy with it either. I did not know tiptap but it looks really cool, a bit similar to slate but probably a better fit for a vue application if I understood it correctly since it is not react based. Will try to put something together some time.
It might make sense to migrate the editor before migrating to vue 3 given vue-easymde won't really work with vue 3?
As the next Vikunja release is just around the corner, I'd like to merge this PR after that was released to make sure we have some time to fix eventual bugs without having to issue a bugfix release every time. On the other hand, I think this will be open for some time so we're not in a hurry anyway 🙃
Btw you don't need to force push every time to keep the history clean, we'll squash merge at the end anyway.
Sry for not answering, was busy doing some other stuff.
I realized this pull request is getting to large to handle once. I will split it into parts so that some stuff can already be used in the vue2 version. That will make the diff smaller and easier to handle.
EDIT: see #717
Sure!
Since the pull request is that large I would really not recommend that here. I'm all in for doing this with small changes. But with large ones like this you would loose track of where a change came from and why it happened.
I'll try to make the commits as dense as possible. I'm doing this anyway because else I would loose track of the changes :)
a5a3bc3dae
toa9e8310839
a9e8310839
to5a7979f23e
Regarding vue-easymde: The changes made to support vue3 are that small that it doesn't make sense to use the new version. As long as there is no further development I would keep the change I did as is.
The link to the commit might brake in the future, since I force-push this branch to keep it update. If that's the case search for the commit with the message
feat: forked vue-easymde
.5a7979f23e
tob4af0ffc01
b4af0ffc01
to9b3c0c4adb
9b3c0c4adb
to1806a3a5c4
1806a3a5c4
toaeabc42844
I could resolve the issues with vue-easymde.
The styles of CodeMirror were missing in my fork.
I'm not sure how they end up in the npm bundle of vue-easymde but I couldn't find a direct import.
I checked out the updated vue 3 version again (v2.0) but most say it's of poor quality. E.g. one thing that is missing are the changes on the life cycle hook names:
Mine (ignore the wrong indention) vs v2.0
It's a lot of effort to keep this branch in sync with the main branch :)
Maybe we can tackle the remaining errors together and split them somehow?
I'm not sure how to solve some. I have some changes in my local stash with some ideas how to fix some problems, but they introduce new problems. So might be good to exchange ideas.
Sure! Maybe it would make sense to create new issues to split up the tasks?
I'd also be open for a discussion via jitsi (or similar) if that simplifies things.
Closing this in favor of #815