hyperapp skeleton docs

[jurij-jukic]

• completely removed resources folder, so the extensive outdated docs are gone, now we just have example-apps

A bit about how i got here. I tried to oneshot 6 different sample apps, and i logged the errors which they made. Consistently it was:

• forgetting to add caps in manifest.json
• forgetting to request networking in manifest.json
• app specific compile time errors (usually around rust borrowing)

Other "happened once" errors are:

• bad imports, not using hyperware_process_lib
• TS data type keys in camelCase instead of snake_case

Most of these were solved by the docs. Except compile time errors around borrowing, those can be copy pasted and solved easily, and future llms probably wont make those.

Note - the 6 apps were: p2p todo, p2p chat, p2p file share, distributed kv db, collaborative notepad, voice chat room
(It failed voice chat room irrespectively of the docs, and other ones were mostly successful).

Imo what the docs should be optimized for is warning about small gotchas, and containing simple patterns. My current iteration of docs is optimized for codex, so they might not be as good for claude. But priority is to avoid bloating and extra debt over time.

[jurij-jukic]

#392
#387

@nick1udwig please check that this PR satisfies the spirit of 387

[nick1udwig]

moving in the right direction 👍

were you following the two-step method described in the readme? Can you explicitly put your prompt/convos for one of the apps here or in the chat? I'm curious because in the past we discussed making vs not the IMPLEMENTATION_PLAN, and if we're past the point that that is a useful thing to do, it may be the case that we should get rid of that part of the README

i think we can potentially do more in terms of "summarizing". E.g., we could potentially describe each example-app in a sentence and then have another sentence to the effect of what patterns/usage is shown in that app

[nick1udwig]

probably worth noting here that the uint there is the timeout in seconds

[jurij-jukic]

Done.

[nick1udwig]

probably want real json:

"request_networking": true

[jurij-jukic]

Done.

[nick1udwig]

put sentences on a newline

llms/markdown renders it the same, but it makes it easier to maintain because the diffs are more readable

[jurij-jukic]

Ahhhh, i remember from a while back. Wrecked by newlines...
Fixed.

[nick1udwig]

• add to README info that *Request and *Response are not valid type names and to use alternatives

[jurij-jukic]

were you following the two-step method described in the readme? Can you explicitly put your prompt/convos for one of the apps here or in the chat? I'm curious because in the past we discussed making vs not the IMPLEMENTATION_PLAN, and if we're past the point that that is a useful thing to do, it may be the case that we should get rid of that part of the README

I followed the two-step method, but i just asked it to do within one prompt, so like "make a spec and then implement". You are right, I will get rid of that part of the README. Here is a prompt (i didnt even describe the app in that much detail):

Use kit new myappname —template hyperapp-skeleton —ui, (replacing myappname with appropriate app name) to make a template in /hypeware_work, which you will modify to build the following app:

Todo List with P2P Sync
A collaborative todo list where items sync between nodes.

Write a spec, and then implement it step by step. Use the README.md given in hyperapp-skeleton to find instructions on specific details. At the end, i should be able to kit bs —hyperapp and test manually that the app works.

---

i think we can potentially do more in terms of "summarizing". E.g., we could potentially describe each example-app in a sentence and then have another sentence to the effect of what patterns/usage is shown in that app

We have something in that direction already.

kit/src/new/templates/rust/ui/hyperapp-skeleton/README.md

Lines 221 to 222 in 1b184bc

	`sign` and `id` demonstrate local messaging.
	`file-explorer` demonstrates VFS interactions.

So we can list the patterns we want to showcase, and find an example app for each, to add into example-apps.
E.g.

• local messaging: id, sign
• remote messaging: ? (can't use chat since its not a hyperapp)
• HTTP handling: anything with a ui, so file-explorer should work
• WS handling: spider?
• VFS interactions: file-explorer

Wdyt? Any apps come to mind? Any other important patterns?

[jurij-jukic]

772b836 removes the old prompt, and adds a shorter one.

[jurij-jukic]

Requests in conversations resolved in details.

• add to README info that *Request and *Response are not valid type names and to use alternatives

Done in naming restrictions

[nick1udwig]

resources folder still seems to be there

otherwise lgtm ⚡

[jurij-jukic]

So we can list the patterns we want to showcase, and find an example app for each, to add into example-apps. E.g.

• local messaging: id, sign
• remote messaging: ? (can't use chat since its not a hyperapp)
• HTTP handling: anything with a ui, so file-explorer should work
• WS handling: spider?
• VFS interactions: file-explorer

Wdyt? Any apps come to mind? Any other important patterns?

@nick1udwig I think u missed this part. What do you think about adding spider to example-apps, and possibly sth else as well which can demonstrate remote messaging?

[nick1udwig]

lgtm ⚡