vuex-orm / vuex-orm-next

The next iteration of Vuex ORM.
https://next.vuex-orm.org
MIT License
189 stars 11 forks source link

Alpha release #126

Open sinasita opened 2 years ago

sinasita commented 2 years ago

Sorry for this post, it's not a real issue or feature request, the question is more about the general development of vuex-orm. Will there be an alpha-release or is the development kind of shut down and there won't be releases anymore? We managed to upgrade our project to vue3 using vuex-orm-next, but there where quite some workarounds necessary to be able to use it. So the question is now, does it have a future or will it die sooner or later and it makes sense to get rid of it and rewrite the code?

vesper8 commented 2 years ago

I would like to know as well.

And @sinasita, were you migrating from a project using vuex-orm with Vue 2? And were you able to retain all functionalities by using vuex-orm-next? I'm at a similar stage, I've been asked to migrate a project from Vue 2 to Vue 3 that uses vuex-orm and I don't know whether to go down your path.. or to rewrite the code to not use a ORM.. which I would feel very sad about since I love this library so much.

Any chance you've written about the workarounds you had to implement? Or any code at all that you can share that could help anyone attempting the same migration as you did?

Many thanks

sinasita commented 2 years ago

Hey @vesper8, well so far, i think there are no lifecyclehooks, it's part of https://github.com/vuex-orm/vuex-orm-next/milestone/1 (https://github.com/vuex-orm/vuex-orm-next/issues/12). So my colleagues wrote an additional plugin be able to use the hooks.

Other adoptions: Before: <Model>.method/query After: store.$repo(<Model>).method/query

Before:Model.query().with('property', (query) => {foo}) After: not able use it anymore

Generally the naming of everything changed (but that's in the Docs), e.g.

Deleting Data before:

    Model.delete(function)
    Model.delete(primaryKey)
    Model.delete([primaryKeys])
    Model.deleteAll()

Deleting Data now:

    repo(Model).destroy(primaryKey)
    repo(Model).destroy([primaryKeys])
    repo(Model).query().delete()
    repo(Model).flush()

I think it works for now, but it would be nice to know what's gonna be the future of vuex-orm.

Good luck and let me know, if you managed to migrate easily

vesper8 commented 2 years ago

Hey @sinasita, thanks for the reply and for detailing some of what's needed to migrate to vuex-orm/next.

Actually, when I wrote the message above I hadn't yet realized that you can use the current (not next) version of vuex-orm with Vue 3.. it works just fine.. same as before.. it's compatible with Vue 3 and the latest Vuex 4. So that leads me to the question.. why did you choose to go with the next branch while it's still in Alpha? Are there any benefits?

charlesbodman commented 2 years ago

Will there be an alpha-release or is the development kind of shut down and there won't be releases anymore?

@kiaking Curious about this question as well. Is development generally paused for now?

dl74i commented 2 years ago

Let me ask the other way around, what was it that you didn't like that had you start working on a next iteration of it? For me personally vuex-orm stable is heaven sent. I love it. It has everything I need. And with vuex being marked as deprecated is favor is Pinia this CodeDredd guy has forked vuex-orm-next and adapted to Pinia. I'm personally not looking for an unstable construct, despite his effort which I welcome.

vuex-orm is the main reason I'm using Vue right now. There is nothing close to it anywhere.

cuebit commented 2 years ago

There are a lot of design decisions that need to be made. The most important of them all is finding a viable solution to distribute a version of this library that supports both state management libraries in Pinia and Vuex. One of the avenues being sought for is a state library-agnostic design that can implement adapters to support common state libraries.

That said, there is the question of what to call this library. Vuex ORM no longer sounds suitable and gives the wrong impression if it's supported for other libraries. But that doesn't mean it shouldn't offer Vuex support out of the box, and allow for adaptable behaviour for other libraries.

Evidently there are lots of things to consider beyond just the general state of this iteration in terms of stability and feature completion.

While there is also a lot of discussion around the "activity" levels of Vuex ORM, there are a lot of discussions being held internally to move forward in the best interest of the library and its user base. Sadly this takes time, and a concerted effort amidst other work that takes precedence, for example @kiaking is actively working on VitePress and Vue ecosystems alike.

As always, people are encouraged to open PRs in way of support, if you feel confident in doing so, and any design/feature requests you may think will expedite development.

CodeDredd commented 2 years ago

@cuebit That sounds like a lot of brain power thinking and work....just thinking loud...you brought me to an idea. Because of the way with composables and that i already have the store decoupled in one file, it should be possible to include vuex ^^.... but great approach. Since there are also still PRs open here i would really appreciate it if you could tell if i should open PRs for "belongToMany" for example. But maybe you wanna first look at my solution.

@dl74i "Unstable" is a bit harsh 😜 .... it always depends. For example i have issues fixed in my repo like vuex-orm/vuex-orm#602 or vuex-orm/vuex-orm#744 .... but i still get your point in terms of "already used, tested & productive". Anyway thanks for feedback!