What are the consequences of wrapping valtio in another layer?

[MatulaDesign]

Hey!

First of all, imagine Janice from "Friends", with the iconic "Oh. My. Gaaawd". This is me when I discovered Valtio :D
Valtio is by far the single most convenient state tool out there. I tried all pmndrs' state solutions (and other libs I could find) to get the expected dev-ex, but Valtio is hands down the best for my style of coding.

Now, all butt-kissing aside, I wouldn't be myself if I hadn't tried making it even more enjoyable for me.
I wrote a small wrapper on top of valtio (because I like using strings to describe the targeted piece of state - sue me) and I was wondering if doing it like this might bite me in the butt somewhere down the line.

Simply put: how naive is this approach? (It works fine, the state updates etc etc)
Should I have used subscribe with subscribeKey? What I did kinda looks similar, but I am not quite sure how these two work, tbh.

PS. TS is still a bit wonky here, but this is just a proof of concept that needs judgement

// store.ts
import { proxy } from 'valtio';

function genericState<T>(data: T): IGenericState<T> {
  return { data, status: { type: 'idle' } };
}

const store = {
  authentication: proxy<IAuthProxy>(
    genericState<IAuth>({ user:  { uid: '123456' } }),
  ),
};

const operator = {
  get: (key: keyof typeof store) => store[key],
  set: <T = any>(key: keyof typeof store, data: (draft: T) => T | void) => {
    return data((operator.get(key).data as unknown) as T);
  },
  status: (key: keyof typeof store, status?: IStatus): IStatus | void => {
    if (status) store[key].status = { ...status };
    else return store[key].status;
  },
};

export default operator;

use

// component
import state from 'store';
import { useProxy } from 'valtio';

const authentication = useProxy(state.get('authentication'));
console.log('authentication', authentication);

state.set('authentication', (draft) => {
  draft.user.uid = '868686' ;
});
state.status('authentication') // if no 2nd arg - get status
state.status('authentication', { type: 'loading' }); // if 2nd argument - set status

[dai-shi]

It looks the store is just a set of proxies and I don't see any issues.
Only a small fix would be: data: (draft: T) => void

Valtio is hands down the best for my style of coding.

Glad to hear that.

[MatulaDesign]

@dai-shi
sweet! you've just made my day ;)

thank you!

[joeynq]

Hi @MatulaDesign
Thanks for your sharing. I'm trying to implement similar things. How about:

// useStore
const useStore = (key) => {
  const state = useProxy(state.get(key));
  return [state[key], operators[key]]
}

// component
const [auth, api] = useStore('authentication');

api.status()
api.set()

@dai-shi is this approach appropriate with Valtio?

When we use:

useStore('state1')
useStore('state2')

in the same component? Does it causes any impact on rendering?

[joeynq]

You're right about scope. It should be as your comment.

About useProxy twice in one component. Is this a good approach for Valtio? In case we need to update both state in one action, does the component render twice?

[dai-shi]

As you useProxy for two different state instances, it's the expected usage. Good point about rendering. I think it works okay. You want to try it to confirm.

[NorweskiDrwal]

EDIT: oh dang it. @MatulaDesign is my other account guys, sorry.

@datnq
I have been thinking about this approach too, but I decided no to go with a wrapper for useProxy and tupling state and operators. Why? Separation of duties and mindful DRYing :D

I treat app's state as a module (local storage would be the best comparison). In my mind, being able to operate on state from wherever is an absolute necessity and should be a pinnacle of every developer's approach ;)

Remember, sometimes you just want to read and/or react to state and sometimes just operate on it without having to know what happens. Valtio lets you do exactly that. It's just a perfect tool for treating state as a separate module of your app, and not some frail addition that depends on some other logic to handle it.

Now, in my mind, if you tuple state and operators using Valtio (like you suggested), you beat the purpose of it being a separate module storing your state. You make it dependent on React's rules of hooks. And you can no longer use it from wherever as a module (because it's stuck within React). Technically, you could go around it and use proxy and useProxy separately, but then you not only break the DRY rules (which I think are stupid to some extent and AHA is the best approach), but also introduce confusion by handling state in multiple ways.

Making it a hook that returns a tuple forces you to do this:

const [, api] = useStore(key); // if just want to operate on state
const [state] = useStore(key); // if just want to read state

Not only does it look ugly, it also (I imagine, because I can't write tests for shit) makes it weird to test? I am not sure about additional rerenders, but there's a reason why there are rules of hooks and why you must have use when it's a hook. React in it's core is just a bunch of arrays of strings (I oversimplify ofc), but I am sure it knows when a hook is used. What I don't know is whether it reacts to the changes of a hook, or to the changes of the hook's props ()?

So, all above is why I decided not to trap my Valtio state inside React--React has not been designed for handling global state. It's been designed to display data. It's a root level UI library (works on DOM), so let's treat it this way ;)

The reason I wrote the proxy operator in the first place is not only that I wanted it to look pretty to me (lol), but also because it was easier for me to wrap my head around how I want state in my apps to be managed. Yeah, no, mostly because it looks prettier to me that way :D

I strongly encourage you to experiment and find your path, but I also want you to think about using tools right for your needs and reasons for using them :)
Trapping Valtio inside a hook like that nulls everything that's good about Valtio in the first place. You can use a monkey wrench as a hammer, but why? ;)

@dai-shi
What did you guys have in mind writing Valtio?

[dai-shi]

I would like to provide a building block. Valtio provides a proxy object that works like a normal JS object as much as possible and it can intuitively be used in React.

[NorweskiDrwal]

I would like to provide a building block. Valtio provides a proxy object that works like a normal JS object as much as possible and it can intuitively be used in React.

Right, so @datnq it's really up to you how you use it, but do consider the reasons I mentioned above ;)