Motivation behind the big API change in v6?

[damnjan]

I stumbled upon this library recently, before the v6 version, and what drew me to it was the API that seemed so easy to use but has now been completely abandoned. I'm talking about switching to using string literals instead of direct objects/functions. Example:

store.use.firstName(); // v5
useStoreValue(store, 'firstName'); // v6

So I'm wondering, why make such a drastic change and not make it backwards compatible? I can imagine migrating a codebase from v5 to v6 would be a huge pain. Or is there something that I'm missing?

Anyway, aside from that and my personal distaste of string literals, they have one big problem and that is refactoring.

Here's what I mean:

const store = createStore({
  name: 'John', // rename this key
})

function App() {
  const name = useStoreValue(store, 'name'); // won't get renamed

If we wanted to change the store field from name to firstName and we used an IDE rename feature (WebStorm, VSCode), we would be left with old string values and would have to change them manually everywhere. I imagine this would be a tedious task for anything but a tiny codebase.

With the previous API version, it would work without a problem.

I'd just like to point out that I'm not actively using this library, I was just playing around with it trying to evaluate if I'm going to use it in my next project, so I might be missing out on something, but I'd like to hear your thoughts on this.

Would you consider adding back the old API as an optional way of using the library?

[zbeyens]

That’s a solid argument about refactoring. I’d be open to adding back the old API as an alternative, maybe through store.set<Name>, store.get<Name>, store.use<Name>, if that fixes the refactoring issue.

The main reason for the new API is to align with React Hooks rules, especially with the new React compiler, and was inspired by Ariakit stores.