Create - task_messenger #2
Comments
tasks -
|
|
feedback i think all these tasks you mention are great, but i would start with the "addition of chat log" and "communication between users" and then "CRUD for task" :-) The communication probably needs a link to be copy/pasted for other users to join. I would say clicking a task should display that link in the or task room title bar or something like that. The level or depths of task tree can be infinite. Important task is that a single "task" in the tree can have multiple parents. There are examples of that sketched in the old issue 56 wizardamigos/wizardamigos.github.io#56 For example towards the end of this feedback comment and again here I do think we will need to go through these old worklogs and feedback comments a lot. Please try to read through it over time top to bottom, as it will likely answer many questions about many details and then we can still discuss :-) Finally, i do think, the button "create task" already falls under CRUD and every time possible, let's not do overlay form, but make make the title in the file explorer editable and/or add a new one at the right indentation level (if it is a sub task) and let's write it out there. One thing though - it HAS to work on mobile, hence "context menu" (right click) is problematic and we need to find alternative techniques for it for all interaction. |
tasks -
|
|
feedback Looks good. It's a bit buggy for me, but i see the progress.
Regarding multiple parents, this is already drawn in the comments i linked. I will link them here again, but you have to read them to the end and see the emoji-asci drawings.
Have you checked those specific linked feedback comments from my last feedback? Here they are again - especially towards the end of each long feedback comment
Here a snippet from the first linked comment: The above shows "inputs" and "outputs"
In summary, see next: Above you can see the inputs have an e.g. The same we have in the second comment for tasks. Here above you can see the
about code
I get that Now that message content might be delivered in the We are currently not yet using refs. For example, to indicate a message is a reply/response/reaction to a previous message with the following BASICALLY: Let's just think of the const id = opts.username
users.forEach(user => {
const message = {
head: [id, user.id, user.mid++],
refs: {},
type: 'on_create_task',
data: { value: input.value, id: task_id }
}
const shuttle_message = {
head: [id, channel_up.send.id, channel_up.mid++],
refs: {},
type: 'send',
data: message,
}
channel_up.send(shuttle_message)
})
const id = opts.username
users.forEach(user => {
const message = {
head: [id, user.id, user.mid++],
refs: {},
type: 'on_post_msg',
data: { value: content, id: chat_id }
}
const shuttle_message = {
head: [id, channel_up.send.id, channel_up.mid++],
refs: {},
type: 'send',
data: message,
}
channel_up.send(shuttle_message)
})Basically, it is important to know the destination address, which i supposed should be knowable, by clicking on the messenger interface of "bob's" messenger, to copy/paste bob's address and maybe combined with a task id to the clipboard and then going to "ana's" messenger interface and clicking e.g. "join" and then paste the task id and/or bob's address ...and in the input event handler from clicking join, we would use that data to send a message from bob to ana and also from ana back to bob and so forth. We can store ana's address (maybe the clipboard would even contain ana's nickname to store it as an Now when the intermediary (e.g. the parent component) receives such a message of The intermediate receiver also checks for e.g. Every next intermediate receiver before the final destination just copies over **This allows the final receiver to reply with a message back and set the // FINAL RECEIVER:
node.on(message => { // received by last inermediate sender
// ...
const reply_message = { ... }
replay_message.type = 'send'
// ...
reply_message.data.refs = {
cause: message.head, // last intermediate sender
}
channel_up.send(reply_message)
})Now the first "intermediate receiver" for the "reply message", will again see there is not They will check the IMPORTANT NOTE: The Your question
A: Bob does NOT know. Everyone has their own unique set of tasks, only some tasks are synced - maybe the UI should indicate if a task is a shared task (we could use: Only "some" tasks are synced, based on what bob and ana share "out of band", which means, e.g. by ana clicking on her messenger to copy/paste an invite to a task and then e.g. by bob pasting that invite and joining that specific task. Now if Also, there should be a way to QUIT a task again, but it isn't deleted, because bob can still re-join the task with a new invite. Your proposal tasks sound good. let's do them, but let's also take extra care for having the things you already implenmented "bug free" :-) |
todo - 2024.04.08
worklog |
|
feedback The feedback for this worklog is part of this comment: |
tasks -
|
|
feedback First the refactoring feedback. refactoring1. data structure+1 for generating a separate file for each peer (e.g. data_bob.json, data_ana.json)
{
rooms: {
'': [{ head: '', type: '', data: 'hello', meta: { date: 12315262345235 }}]
'bob': [{ head: '', type: '', data: 'hi', meta: { date: 12315262345289 }}]
}
}
old feedback:
old feedback:
this seems to be missing. When a fresh task is created, it should have at least one message in the chat log of the person who created the task, which is a system message with the parameter arguments which were used when creating the task.
2. container for elements3. code deduplication
const space = ''
const grand_last = last ? 'a' : ''
const prefix = last ? '' : ''
const opts = { space, prefix, grand_last }
const element = html_template(opts) // for exampleThe idea is to make a function, e.g. Anyway, one thing that would be good if we at least turn event handler into functions: // e.g.
inp.onclick = () => {
if(inp_open){
inp.innerHTML = '🗃'
out_open ? out.innerHTML =
//...
}
}
// becomes
inp.onclick = inp_onclick
return
function inp_onclick (event) {
if (inp_open) {
inp.innerHTML = '🗃'
out_open ? out.innerHTML =
// ...
}
}
// that way reading becomes a bit easieropts refactoringLines 75 to 93 in 062c3b8 The @alyhxn could you at the end of your work and before recording the next worklog always double check the last feedback to see if anything is missing or was forgotten? that would be sweet :-) |
|
feedback I watched the That's 1000 * 100 * 10 * 10 = 10_000_000 tasks On my computer, a loop with so many tasks {
var t0 = performance.now()
var x = 0
for (var i = 10_000_000; i--;) {
x += i
}
console.log(x)
var t1 = performance.now()
console.log(t1 - t0)
}Takes ~300ms to run. So we can increase some task levels to make it take 2-3 seconds or even 30 seconds. And then we can benchmark our task messenger structure to see that completly removing and adding tasks nodes to the DOM keeps constant performance, regardless of the amount of tasks. And it also keeps constant memory footprint. These things can also be inspected in the developer tools and i can share some resources how that is being done. about architecture
|
tasks -
|
|
feedback Thanks. Looks like a good worklog. Here some additional feedback: 1. later todosit would be good if all the tasks you spot that are for "some time later" would be added as todos in the top level comment of the issue, so we wont forget them :slight_smile: that way, the top level issue can slowly collect tasks and sub tasks to represent our future plans and roadmap for where we wanna get to :slight_smile: e.g. a task to remind us of: data_bob.json, data_ana.json, etc... should be exported directly from DB module and later imported into DB module as well Basically, when processing feedback, ...either it should be included into the work for the next worklog, or if it cant be done right away, it should be added as a todo for later so we will for sure not forget it e.g. if that feature depends on some other task, that should be indicated by using the output of that other task as input to the "reply" feature task that requires having a DB module first, so the DB module as output should be an input to that export/import task for the future :slight_smile: 2. message formatRegarding message format, it has a very specific and very strict format, which looks like this: on(message => {
const by = `<address of sender>`
const to = `<address of receiver>`
const mid = `<message ID counter>`
// `mid` indicates how many messages have been sent from "by" to "to".
// -> if there was a DB book append only log to store the sent messages from "by" to "to", then `mid` would be `.length` of that append only log
const head = [by, to, mid]
const refs = {}
const type = 'text'
const data = 'Hello back'
const meta = { date: Date.now() }
const msg = {
head,
refs,
type,
data,
meta,
}
// `msg.refs` is an object
// every key, e.g. `msg.refs.cause` value is a `head` of another message
msg.refs.cause = message.head
console.log(msg)
book.add(msg)
const {
send
} = state.net[message.head[0]]
send(msg)
})every message has exactly that structure and not any different structure. we should probably write a function to verify that structure. 3. derived append only logsI do think this is also supposed to be true for Ideally, the chatroom would only consist of an ordered list of That way we dont have to duplicate data for now and keep things more systematic. Things is also, the 4. some old feeddbackmaybe you missed one tiny old feedback, the old feedback about the json data structure and you jumped directly to the But it also shows the
the otherwise, thanks for the worklog. Agree with not touching the list architecture branch until we completed the other refactoring parts :slight_smile: |
tasks -
|
|
Tasks -
|
todo@input📦 serapath_discord_msg@output📦 task_messenger_v0.0.1 from comment@input📦 task_messenger_v0.0.1 from comment@input📦 david_mobile_v0.0.4@output📦 task_messenger_v0.0.2 from comment@input📦 task_explorer_v0.0.1 from comment@input📦 task_messenger_v0.0.2 from comment@output📦 task_messenger_v0.0.3 from comment@input📦 task_messenger_v0.0.3 from comment@output📦 task_messenger_v0.0.4 from comment@input📦 task_messenger_v0.0.4 from comment@output📦 task_messenger_v0.0.5 from comment@input📦 task_messenger_v0.0.5 from comment@output📦 task_messenger_v0.0.6 from commentDBModule@input📦 [DB_v0.0.?]@input📦 [IO_v0.0.?]The text was updated successfully, but these errors were encountered: