Should we support direct acess/assignment?

[jmeistrich]

Legend-State 1.3.0-next.0 adds an experimental new feature: using a _ prefix as a shorthand for get/set. This allows direct access and assignment, which is shorter and easier than using get()/set(). What do you think? Is this an improvement that you would use?

const obs = observable({ fname: 'hi', lname: 'there' });

const fname = obs._fname;
// is the same as
const fname = obs.fname.get();

obs._fname = 'hello';
// is the same as
obs.fname.set('hello');

// Multiple reads looks cleaner
const name$ = computed(() => `${obs._fname} ${obs._lname}`);

We're not planning to remove get/set - this is an alternative which some people said they’d find easier to use. Many teams prefer the safety of calling set() to modify state to prevent accidental changes, so we have a way to disable it entirely.

import { configureLegendState } from '@legendapp/state';
import '@legendapp/state/types-safe';

configureLegendState({ enableDirectAccess: false });

I think this might make Legend-State more approachable and familiar to use? As I'm experimenting with it, I find I prefer the clarity of value.get() within React components, but _value feels shorter and friendlier within computed/observe. I'm curious what all of you think 🤔

[SMhdAsadi]

I am not quite familiar with internals of this library but is it possible to add support for using observables in this way?

const obs = observable({ fname: 'hi', lname: 'there' });

const fname = obs.fname;
// becomes the same as
const fname = obs.fname.peek();

obs.fname = 'hello';
// becomes the same as
obs.fname.set('hello');

const fname = obs.fname$;
// becomes the same as
const fname = obs.fname.get();
// $ can refer to some magic work :)

// and for accessing the observable itself, we could call another method on it
const actual_obervable = obs.fname.obs() // or anything you would prefer

I really like this way of working with observables since I mostly work with values other than observables.

[jmeistrich]

@SMhdAsadi Accessing a normal property needs to return an observable child, so that with large hierarchy you can dot through to deep children. We did experiment with trying to return the raw value when accessing leaf nodes in an early version but it was very confusing to use.

We ended up releasing an experimental version of this in version 1.3.0: https://legendapp.com/open-source/state/experiments/#enabledirectaccess

It uses a $ property to alias get and set. And we're also experimenting with a direct peek using _ that you can see on that page.

import { observable } from '@legendapp/state';
import { enableDirectAccess } from '@legendapp/state/config/enableDirectAccess';
enableDirectAccess()

const obs = observable({ test: 'hi', num: 0 })

// $ is a shorthand for get()
const testValue = obs.test.$

// Assign to $ as a shorthand for set()
obs.test.$ = 'hello'

// Assign objects too just like you can with set()
obs.$ = { test: 'hello' }

// Incrementing works as you'd expect
obs.$ ++

What do you think of that approach?

[SMhdAsadi]

Oh, you're absolutely right. I completely forgot to take deep observables into consideration.

Regarding the direct peek, personally, I find it challenging to understand. The use of an underscore reminds me of private fields, so the concept of peeking isn't the first thing that comes to mind. However, I do appreciate the ability to set observables without triggering notifications (which I believe is currently missing).

The utilization of the use function is a clever approach. It provides a descriptive and user-friendly experience when used in React components. Nonetheless, there is one drawback to this function. What happens if we employ it outside of React components? As it is a hook, it can lead to some errors if mistakenly placed after an if statement for example. Maybe some babel plugin could find usages of use function inside React components and adds a useSelector on top of that component?

Lastly, concerning the direct access, I don't find it sufficiently descriptive. It lacks clarity and makes the learning process of this library more challenging.

[jmeistrich]

The use function just calls useSelector under the hood, so it would do the same thing that React hooks do normally - console logs if used in the wrong place. Unfortunately it wouldn't show warnings by eslint because it's not directly a hook... I think the tradeoff is worth it though? I'm quite liking use() myself and considering favoring it in the documentation as the primary way of using observables in React, and treat useSelector and observer as more advanced options?

I'm still not sure how I feel about the direct access - I like that it's less verbose and direct assignments like incrementing with val.$ ++ feels nicer than val.set(v => v + )`. But I agree that it loses some descriptiveness. We will keep it optional for now and I'll hold off on emphasizing it in the docs until we have a stronger feeling about it.