vobyjs / oby Goto Github PK

Is it possible for an effect to not trigger initially?

const test = $(false)

$.effect(() => {
    console.log('update', test())
})

SetTimeout(() => test(true), 100)

would log test two times.
It would be nice if we could have a flag to "not trigger on effect creation", and monitor only future changes.

Or am I blind and there is a config value that can make that possible already?

Hi Fabio,

While voby is still 0.x, I'd like to suggest a change to the Observable API.

In a nutshell, I believe overloading is more or less "bad for everything".

The current API is triple overloaded:

type Observable<T> = {
  (): T,
  ( value: T ): T,
  ( fn: ( value: T ) => T ): T
};

It's misleading. An observable is not a function - it's actually an object with 3 methods.

Modeling it as an overloaded function favors writing code fast and sacrifices readability - producing code where every method call is ambiguous, with $value(...) essentially saying "do something with ...", requiring (A) the programmer to parse to ... expression and figure out what it does, and (B) the run-time to dynamically type-check values.

What I would propose instead:

type Observable<T> = {
  (): T,
  set( value: T ): T,
  update( fn: ( value: T ) => T ): T
};

Words provide semantics, making for more readable code:

const $count = $(0);

const increment = () => $count.update(prev => prev + 1);
const decrement = () => $count.update(prev => prev - 1);
const reset = () => $count.set(0);

I know this is somewhat opinionated, perhaps bordering on bikeshedding territory, and it's a big breaking change. But it might eliminate some (however slight) run-time/complexity overhead, and avoids beginner questions/mistakes such as "how to put a function in an Observable?".

Admittedly, this suggestion is mostly opinionated. It probably comes mostly down to personal preference. Although I think, objectively, seeing the words update or set where those operations take place seems pretty reasonable - overloading does not help readability.

Whether you think writing or reading is more important of course does come down to opinion, but in my experience, code is read more times (by more persons) than written.

Just something to think about and consider. 😇

I have been using TypeScript 5.x in a new project and I have noticed that when I press F8 to track errors, VSCode often jumps to the node_modules/oby/tsconfig.json file and prompts me that it cannot find the tsex/tsconfig.json file. This also causes a lot of import statements in the node_modules/oby/src directory to be marked as red errors when I browse through the code. I hope that these tsconfig.json files can be excluded when the npm package is released next time. I also hope that the same setting can be adopted in voby.

Currently $.for has some performance issues when handling primitives, especially if they could be found in the array multiple times. That should probably be addressed by adding a normalization step that maps primitives to wrapper objects, to get a non-primitive reference for caching purposes.

Just an FYI - I'm seeing a (!) Circular dependencies warning when using this lib, mainly around "context.js" by the look of it.

Nice work, though!

@fabiospampinato

I've been running into a lot of difficult-to-debug issues around infinite loops involving arrays and circular references. Here's a sandbox with a sample of what I'm talking about:

https://codesandbox.io/s/voby-demo-store-counter-forked-r225g4?file=/src/index.tsx
(click the + a couple times and the app will hang)

This has been a bit difficult in my app because Solid handles these circular references in arrays just fine and I have data of a similar shape cropping up in numerous places in my app. So this looks to me like a bug, but what do you think? Are these cases something that voby/oby should handle? Or does there just need to be a big warning sign in the readme?