21gramconsulting / usetaskqueue Goto Github PK

Ok, so our internal solution has storage-based features.
Local, session, you name it.

The problem of course is that synchronization between open runtimes & stuff contains some proprietary IP which I'm not willing to release (for at least this year).

The task is to come up with a simple primitive basic solution that's good enough for open-source.
There are some implementation sketches, and we keep the API open, as in, this library pretends to provide the feature based on its function contract, like with the expectation to provide a codec.

This stuff will be added with a minor release.

A task queue's input queue is processed as soon as we put something into it. That behavior is correct.

As soon as processing starts, the items get popped from it. That is also correct.

Therefore it may seem like it's redundant, but it is not! It serves the purpose of when in a react application a lot of things happen, during, between, before, or after a render for example, things may hang around.
This is why we use the dispatch set action approaches instead of simple setters.

Now, all that said, we should somehow create UAT tests for such cases. I didn't have any ideas yet, but most likely it's trivial.

As a user of the library it's normal to do this:

      useTaskQueue({
        name: 'test',
        codec: json.number,
        task: v => [v * 2, v * 3, v * 4],
      })

The problem is, that doing so in a react component or a wrapper hook, the task function's reference will always "change" therefore React will assume, that our memorized value should be re-evaluated.

  const task = useMemo(() => descriptor.task, [descriptor.task]);

Gotta somehow fix react's function change detection.