[Not TS specific + frontend]

[pulsar beacon]

Guys, I have a question, lets say I have a js app running in 2 threads, one worker thread and the main ui thread. and I have a virtual document dom for richtext.
should you be able to do changes on the richtext dom, and that would send promises to the worker or would you force people to write addons in a way that those mutations are executed in the web worker, so that there they run sync and its confirmed that the requested change will go though
it will be always sync in the worker thread and always async / readonly in the mainthread

[cinder nimbus]

If there are risks of things like race conditions or conflicts, then I would have a single process manage those changes - the worker

I say this based on general experience/understanding. I havent used workers, nor do I know exactly what you are doing

If might work each way, that is just my first instinct

Having a manager process generally makes things simpler

Is the richtext VDOM a virtual representation of a rich text in the memory of the worker process? Or is it somewhere else?

[pulsar beacon]

@cinder nimbus thats what im doing.
Basically the main thread handles ui, but it also has a synced dom, that synced dom would then be in that case readonly, and you need to send commands requesting a change to the backend

[pulsar beacon]

ye in the memory of the worker, in reality its a full simulated website with a css, html, animation, js and other trees

its a webbuilder, richtext was a simpler example

thats why i go multithreaded

[cinder nimbus]

hmm

[pulsar beacon]

and even allow for multiple workers which do co processing / data analysis, i was planning to either send on those threads changes req as promises or not allow them at all

[cinder nimbus]

It's always 1 UI process and 1 worker process? What does the worker process do other than this?

So, the UI is going to edit this VDOM, what are the workers doing with it?

[pulsar beacon]

workers run plugins, (exampel tailwind classing, multiplayer syncing etc, and a 2nd worker pre calculates all css styles)

Wait

can I dm you?

[cinder nimbus]

No

[pulsar beacon]

I send you some notes

ooh okay

but yeah, one "main" mutating shared worker per project

[cinder nimbus]

Hmm, so do you have to do processing of the VDOM created by the UI thread, so that you can display a preview?

[pulsar beacon]

the rest have it as readonly / or send req to that htread

[pulsar beacon]

other way around, the worker has the entire vdom, and the ui thread does processing to preview it

and preview tabs

you can have multiple tabs previewing the same project

[cinder nimbus]

ah

[pulsar beacon]

and edit at both

[cinder nimbus]

multiple people can work on the same doc?

[pulsar beacon]

yep

[cinder nimbus]

Well almost certainly you need a master

and that probably should be the server if you can have multiple clients

[pulsar beacon]

i know, but the question was, do i forward cahnge req to the master, or do i leave extension devs on their own to implement a communication protocol for themselfs

[celest nymph]

You can have a shared worker (between tabs)

[pulsar beacon]

i know, projects are shared workers

[celest nymph]

Doesnt help if other users do stuff though

[pulsar beacon]

i handle that via a server who runs the psot plugin processed vdom as well

[celest nymph]

I use event sourcing for that, works well enough but you still need to handle conflicts

[cinder nimbus]

If one user adds a child, and another use deletes the parent of that child at the same time, trying to resolve those requests gets tricky

[pulsar beacon]

i basically use json patch operations and multiple transaction queues to sync changes

[cinder nimbus]

I guess it's tricky either way

[pulsar beacon]

that would be a race condition and throw a user at the user who is slower

yeah

luckily most things have an id, (im programming rn a modified json patch using primarily ids, and relative paths)

so it will be slightly more resistent to thsoe things

[cinder nimbus]

where does extension devs come into it?

[celest nymph]

It's really just the same as a merge with conflicts

[pulsar beacon]

they can write plugins for: the ui thread, the shared worker thread, (spawn custom worker with readonly) / a build plugin (during project build) and maybe (a big maybe) server extensions

so yeah, 5 envoriments

6 if we count preview ui thread as well

[pulsar beacon]

i feel like those are things i can resolve easier later on

[celest nymph]

What else is there to solve?

[cinder nimbus]

Feels like if you are building this, you should be able to understand the issues of networked programming 🤷🏻‍♂️

[pulsar beacon]

my main concern is mostly with writing a nice api for the devs

[cinder nimbus]

It's details rather than general. Somehow you have to have a master and handle requests and conflicts.

[celest nymph]

Ah right you're the guy who wanted a json rather than an history

Forget I'm here

[pulsar beacon]

ye

[pulsar beacon]

yeah

tbh i kind of feel confident (prob idiotically) that i can solve it

[cinder nimbus]

There's not really enough information for me to make specific comments, and I'm fine with that

[pulsar beacon]

but my main axiety comes from how i should design cross thread communication regarding mutations.

[pulsar beacon]

sorry

[cinder nimbus]

Just take a breath, and think about it, I think you can work it out

[pulsar beacon]

yeah,
let me note my toughts down.
on the worker thread we have as an example an vNode with an id and tagname.
on mutation those get relayed to the main ui thread via json patch.
now there they get applied to the readonly representation.
good so far

only issue is, lets say user wants to change now an element,
do i have a specific command like: worker.req(id, property to invoke, parameters)?

[cinder nimbus]

I guess you want an interface like an HTML dom?

[pulsar beacon]

yep

or do i relay changes, so if i do vNode.tagName = "a" I return a promise, and relay that to the worker thread

[cinder nimbus]

But when you make a change, it has to be async, and return success or failure

[pulsar beacon]

yeah

[cinder nimbus]

and maybe don't allow any changes based on that change until its resolved

which would be natural with a promise that didn't resolve until complete

[pulsar beacon]

yeah, also afaik post messages to worker are in order, so it should not be too big of an issue?

[cinder nimbus]

No clue

I don't know if order matters. Only matters what the server accepts/rejects

unless you're talking about something different

[pulsar beacon]

Basically those two options

myNode.a = "t" // return promise
OR
myNode.a = "t" // throws
// I have to do this
worker.send(jsonpatch for that change

[pulsar beacon]

id say we can for now forget the server, and focus on the worker

the worker / main ui communication design is the main issue i have atm

[also the 2nd problem stuck in my head]
I have multiple classes like VNode, VComment, VElement, VIsland (customizable for cases where people want to add island rendering for react vue etc)
Do i sync those classes / store them on these nodes as well?
So basically my patch operation for a new Class has the class type on it as well.
or do i leave them as plain objects / maps / arrays etc