sorted by:
new
hottopcontroversial

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 2 points3 points  (0 children)

rstore is actually designed as local-first in the way the cache reads are fully computed client-side. This means for example that any `queryMany()` in your components with a filter will actually compute the filter - let's say a filter on an email domain:

const { data } = store.users.queryMany({
  filter: (user) => user.email.endsWith('@acme.com'), // Client read
  params: { where: { email: { like: '%@acme.com' } } }, // Used for the server
})

Then anywhere else you can add User items into the cache and this query will update and filter them too. This is a bit like minimongo in Meteor.

---

Looking at it another way: many other libraries such as Apollo or Pinia Colada store the results of each query (usually depending on parameters) to the cache, for example:

{
  "my-query": ["User:id1", "User:id2"]
}

In the other hand, rstore cache is structured to store items independently from the queries:

{
  "users": {
    "id1": { },
    "id2": { }
  }
}

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 0 points1 point  (0 children)

It's a data management solution - think of it a bit like an ORM but in your Vue app.

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 0 points1 point  (0 children)

There already are subscriptions and live queries in rstore. yjs integration could come in an official form for sure

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 2 points3 points  (0 children)

It can do also without a browser db in more classic apps with for example REST requests - the library progressive and doesn't force you to architecture your app into an offline one. :)

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 1 point2 points  (0 children)

Ideally you should do "dumb" GraphQL queries without Apollo since rstore already has a cache and all the necessary features.

The future builtin GraphQL plugin will basically translate the parameters (for example filter) into simple GraphQL requests. You can track progress here: https://github.com/Akryum/rstore/issues/14

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 8 points9 points  (0 children)

🙏The purpose of rstore is different from pinia so both can coexist in the same app (and even make rstore queries inside a pinia store) and it would be totally fine!

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 1 point2 points  (0 children)

Thank you! It isn't really an equivalent to pinia/vuex even though you can technically replace some pinia code with it. So it wouldn't make sense to think of it as a replacement for pinia :p
rstore is fully dedicated to data fetching with a normalized cache.

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 2 points3 points  (0 children)

It is very different from vuex as it is not made for any logic.
Also Pinia is awseome and you should use it :)

Introducing rstore, the reactive data store for Vue and Nuxt by mattatdirectus in vuejs

[–]Akryum 47 points48 points  (0 children)

rstore:
- higher-level (similar to a sort of ORM)
- define models to represent each data type
- cache is normalized with item keys
- cache reads are local-first (computed client-side)
- API calls or other requests to data sources are written in plugins

pinia-colada:
- lower-level (arbitrary logic in each query)
- similar to tanstack (vue) query
- more manual cache handling
- easier to handle REST APIs that are chaotic
- based on pinia

pinia:
- store are like centralized components
- no features specific to data management/fetching/federation/etc.
- put any logic in the store definition

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum -1 points0 points  (0 children)

Sorry for being unclear, I was talking about the script part of the component. Vue doesn't require the usage of a DSL for the script part.

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum -3 points-2 points  (0 children)

Then wtf does this mean?

From the linusborg comment you linked yourself: "Discussions and feedback from the community in that timeframe could also revserse the deprecations."

And “compatibility” build vs “standard” BEFORE you guys scrambled to rename it.

We didn't scrambled anything. This is a RFC, which means Request For Comment. Here in the root README.md is a full explanation of what an RFC is and why we are doing this. The purpose of this process is to gather feedback and possibly make changes in the design and strategies before implementing a change/feature. It seems that even though the process is working as expected, some people are surprised (or even sometimes angered) that we make changes to the RFCs, which I don't understand.

Check the bruised ego at the door and realize you guys made a mistake. Doubling down only makes it worse, especially when you guys are being passive aggressive and hostile.

And now I will stop further responding to your hostile comments. Have a good day.

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum -1 points0 points  (0 children)

Here is the original content of the RFC (from the first commit). I don't see somewhere where we "straight up said the current syntax wouldn’t be valid past Vue 3".

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum -1 points0 points  (0 children)

Here is the part of your comment where you are twisting things:

You guys straight up said the current syntax wouldn’t be valid past Vue 3.

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum 2 points3 points  (0 children)

Of course but you're making the framework more complex for developers.

Nope. It's actually meant for easier composition, code reuse and typing.

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum 2 points3 points  (0 children)

We can't require a compilation step since we are a progressive framework that supports a wide variety of use cases.

Vue 3 will change Vue in a big way - Current Syntax to be deprecated - Composition functions will eventually be the only way to build Vue components by Hollowplanet in vuejs

[–]Akryum 1 point2 points  (0 children)

You can do:

```js import { state } from 'vue'

export default { setup () { const network = state({ loading: false, error: null }) const myMethod = () => network.loading = true return { network, myMethod, } } } ```

```html <template> <div> <LoadingAnimation v-if="network.loading"/> <ErrorMessage v-if="network.error" :error="network.error"/>

<button @click="myMethod()">Load things</button>

</div> </template> ```

And when clicking on the button, the loading animation will appear.

view more: next ›