vuex-orm-next icon indicating copy to clipboard operation
vuex-orm-next copied to clipboard

Alpha release

Open sinasita opened this issue 3 years ago • 7 comments

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?

sinasita avatar Apr 27 '22 14:04 sinasita

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

vesper8 avatar May 03 '22 14:05 vesper8

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

sinasita avatar May 06 '22 13:05 sinasita

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?

vesper8 avatar May 07 '22 10:05 vesper8

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?

charlesbodman avatar Jul 08 '22 18:07 charlesbodman

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.

dl74i avatar Jul 10 '22 12:07 dl74i

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.

cuebit avatar Jul 10 '22 13:07 cuebit

@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!

CodeDredd avatar Jul 12 '22 20:07 CodeDredd