Refactor - playproject #19
Comments
tasks -
|
|
feedback Regarding "smooth scroll", the page is old and now there is: Let's at least try :-) bel and csjs-inect should be completly replaced For rellax, i am not sure. maybe take a look at the code and if you think it is easy enough to make our own little helper library, go for it, otherwise, we can also keep it for now i guess. Components probably don't communicate because there was not much need for communication, so we can still setup our new component structure, but just not really use any communication, because we don't have anything to commnunicate, which makes it simple. yay :-) Regarding people, I see you added yourself (Ali), but we also have "David" and we have Cypher and Ibrar and it always needs to be easy to add additional people. We will add them later, so you don't have to bother, but at least for yourself, that's fine and maybe you can provide or add an image to your avatar and title, pick whatever skills you feel would be the right fit. You see what others wrote, but maybe you have yet another preferred way of describing yourself :-) |
Tasks -
|
|
feedback Yes, agree with "crazy hard coding". Thanks for worklog. Ibrar is currently working through the playproject as well to see how to improve it UI/UX wise, so maybe at some point you should follow each others worklogs while doing playproject stuff. |
|
Tasks -
Worklog |
|
feedback We need a way to have a "theme switcher" somewhere in the menu. Behind the scenes, it will use the "theme api". In order to provide such a powerful realtime live updating "theme api", we need to maybe follow the ideas i described on discord and maybe you can add or refine those. It needs to take care of:
regarding island sizes So the team section and the supporter section, both have small islands. To not make things boring, we should probably just "randomize" the icon component used to display a supporter island. |
Tasks -
|
|
feedback Good job. Looks fine. Regarding the navigation. // ...
const el = document.createElement('div')
const sh = el.attachShadow(shopts)
const sections = [1,2,3,4].map(n => `section${n}`)
sh.innerHTML = `
<div class="navbar"></div>
${sections.map(id => `<div id="${id}"></div>`)}
`
const shadowfy = el => el.attachShadow(shopts)
const shadows = [...sh.children].map(shadowfy)
const [navbar, sec1, sec2, sec3, sec4] = shadows
navbar.append(navbar(sections))
sec1.append(section1())
sec2.append(section2())
sec3.append(section3())
sec4.append(section4())Now you can use the navigation component and add anchor tags to navigate to sections and those sections are otherwise the id's of the elements that contain the shadow component instances. |
Tasks -
|
|
feedback feedback on discord :-) |
Tasks -
|
|
feedback
On the other hand, we also have never defined yet how things look when you e.g. expand up/down and the entry slot list is still expanded. The design you chose seems sensible, but it should also still show the numbers after the Or maybe there is a mistake. In case we are talking about the former being the "collapsed" mode, then that is not correct. The collapsed mode should look different, see expanded: but collapsed later it looks like Otherwise I get what you say. If we want to "follow" just one design, then we need to decide how that is supposed to look and solve al the "UX problems" and if we have that, we can totally implement that. What do you suggest? For example, let's say and later when still selected and later when unselected This might also solve the on/off toggle for spaced in front of lines as you say. is that an improvement? It might also allow us to improve the a themed version from: to regarding the bold and thin link connecting lines, i feel we should maybe always use thin lines everywhere, but maybe the currently selected path should switch to bold/thick line. That way we don't have ot rely on color to indicate what is currently selected. Another thing we could do is, to indicate the path to all currently open editor tabs in the graph explorer as well using double lines, ...we do have the following options: |
Tasks -
|
|
feedback
Also let's start fixing all bugs and clean up and modularize the code, so the next worklog wont have glitches or bugs anymore and can focus on explaining the code and the modules. |
Proposed Tasks
|
Tasks -
|
|
feedback It's a 20 minutes worklog, that's not good. Here is some feedback for the first 5 minutes, which explain the graph-explorer, which is generally okay.
Regarding styling: To define styling based on inline style variables or attributes. If attributes are used, they should be e.g. <div class=".graph-entry" data-indentation="10">...</div>.graph-entry {
--fallback: 5
width: calc(10px * attr(data-indentation, var(--falback));
}or something like that? I maybe didnt completely understand the essence of the problem yet. |
Tasks -
|
|
feedback
Like this: // page/demo.js
const main = reqiure('main')
const statedb = require('STATE')
const { admin, sid } = await statedb.init(fallback)
const sdb = statedb()
main(sid)
async function fallback (root_db) {
const path = './snapshot.json' // page/snapshot.json
fetch(path).then(async response => {
const data = await response.json()
root_db.populate(data)
}).catch(error => {})
}The benefit of the above is, that we decouple the way "how" we get the default data. Is it an http request? is it hard coded? is it via websocket? is it via webtransport? is it via webrtc? is it via jsonp? is it by prompting the user with a form? ...many things are possible and it also makes our STATE module smaller to not hard code the fetching itself to e.g. later components can do: // src/index.js
const footer = require('footer')
module.exports = main
async function main (sid) {
const { id, data } = sdb.get(sid, fallback, hub)
// ...
}
async function fallback (main_db) {
const data = require('./data.json') // ./src/data.json
main_db.populate(data)
}maybe new components could be added by super components like this: const btn = document.createElement('button')
btn.onclick = event => {
const sid = sdb.add({
"css" : "",
"shared" : false,
"uniq" : true,
"subs" : {}
})
const footer_el = footer(sid)
sh.append(footer_el)
} |
Task proposals
|
Tasks -
|
Tasks -
|
|
feedback Thanks, worklog is okay, but overall still a bit messy or different from what i was looking for in some way :-)
Let's change that and split this as well.
The way we set/get/etc... data in components is not 100% the same as how it is managed internally in furthermore:
Which one is it? also this doesn't look completely in sync with what is presented inside the worklog video Whatever is or was discussed in discord needs to be captured as a commit in the repository. Either updates to the code or in this case also or mainly updates to the graph explorer
data structuresAs presented in worklog, not described in "15": {
"id": 15,
"name": "topnav.json",
"type": "json",
"data": {},
"hubs": [4, 14],
"slotmap": [["hubs"]]
}to "15": {
"id": 15,
"name": "topnav.json",
"type": "json",
"data": {},
"slot": {
"": [["hubs"]] // slotmap is in the empty key
"hubs": [4, 14],
}
}But still, the above in general does not accommodate for slot types properly, especially not the module/instance type. Basically, a link that is mediated by an intermediate instance // foo.js
const bar1 = require('bar')
//
const b = bar(sid)which will lead the "foo" entry to have a link to the "b" instance of type "bar".
It means, that "foo" cannot communicate with "b" without "bar" being theoretically able to interfere.
regarding
|
Tasks -
|
Tasks -
|
|
feedback |
Todo
@input📦 playproject_old@output📦 playproject_v0.0.1 from commentplayproject_v0.0.1@input📦 playproject_v0.0.1 from commentour_contributors.js@output📦 playproject_v0.0.2 from commentplayproject_v0.0.2@input📦 playproject_v0.0.2 from commentsupporters.js@output📦 playproject_v0.0.3 from commentplayproject_v0.0.3@input📦 playproject_v0.0.3 from comment@output📦 playproject_v0.0.4 from commentoutput❓playproject_v0.0The text was updated successfully, but these errors were encountered: