Skip to content

Conversation

tylerchilds
Copy link

Related Issue (if any)

Adds simpleton-client, a custom element for synchronizing text across braid-http.

Currently, this should be regarded as a functional WIP as it depends on https://esm.sh for resolving node_modules-- how should we plumb npm dependencies into the client?

Closes: #[issue number that will be closed through this PR]

Describe the add-ons or changes you've made

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Code style update (formatting, local variables)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

visited the plan1 page and https://sillyz.computer/app/simpleton-client?src=/example and edited text across the boundaries

Checklist:

  • My code follows the "contribution guidelines" of this project.
  • I have performed a self-review of my own code.
  • I have commented my code, particularly wherever it was hard to understand.
  • My changes generate no new warnings.
  • Any dependent changes have been merged and published in downstream modules.

Screenshots (Only for Front End and UI/UX Designers)

Original Updated
Original Screenshot Updated Screenshot

@akhileshthite akhileshthite self-requested a review December 16, 2024 13:23
@akhileshthite akhileshthite added documentation Improvements or additions to documentation protocol New protocol to support :// builds Electron builds labels Dec 16, 2024
@akhileshthite
Copy link
Member

There are two options we can consider:

  1. Bundle Dependencies During Build:
    This involves using a bundler like esbuild or Webpack to package all required dependencies into the client during the build process.

  2. Protocol-Specific Dependency Handling:
    We can create a separate protocol handler, braid-handler, within protocols. This handler will include all necessary dependencies, allowing the client itself to remain static. This approach is already used for the hyper-chat implementation, where all dependencies are managed within the protocol handler, while the client remains lightweight and static. For reference: feat: implement hyper chat application and enhance hyper-handler #5

@tylerchilds
Copy link
Author

Maybe there's a third possible option: an npm:// protocol handler

npm:// would just resolve to the local node_modules folder, keeping the client light-- would this pattern work in peersky's architecture?

e.g.
npm://is-number/index.js would resolve to node_modules/is-number/index.js

i know most of the braid research demos to date are generally raw http handlers or express handlers, with critical node_modules just served as url routes for easy access to avoid builds.

the npm: protocol pattern would also match how deno is approaching compatibility; https://docs.deno.com/runtime/fundamentals/node/

@akhileshthite
Copy link
Member

akhileshthite commented Dec 17, 2024

Maybe there's a third possible option: an npm:// protocol handler

npm:// would just resolve to the local node_modules folder, keeping the client light-- would this pattern work in peersky's architecture?

e.g. npm://is-number/index.js would resolve to node_modules/is-number/index.js

i know most of the braid research demos to date are generally raw http handlers or express handlers, with critical node_modules just served as url routes for easy access to avoid builds.

the npm: protocol pattern would also match how deno is approaching compatibility; https://docs.deno.com/runtime/fundamentals/node/

I like the approach, but I have two concerns to address:

  • We’d need to ensure low overhead for module resolution to avoid performance bottlenecks, especially for large dependencies.

  • Security sandboxing might need to be considered for dynamically loaded modules, especially if untrusted modules are involved.

We can implement npm:// as a separate protocol handler (npm-handler.js under protocols) to resolve dependencies dynamically.

Files:
https://github.com/p2plabsxyz/peersky-browser/tree/v1/src/protocols
https://github.com/p2plabsxyz/peersky-browser/blob/v1/src/main.js
https://github.com/p2plabsxyz/peersky-browser/blob/v1/src/utils.js
https://github.com/p2plabsxyz/peersky-browser/blob/v1/src/renderer.js
https://github.com/p2plabsxyz/peersky-browser/blob/v1/src/window-manager.js

@tylerchilds
Copy link
Author

@akhileshthite I just updated this PR to have the braid-markdown component added, which will syncronize a with a markdown rendered view of the text in a two column layout.

this shows how to decoratively link two components using html attributes-- check the sync function in simpleton-client, which references the data-script and data-action attributes sent from the braid-markdown component-- which also uses import.meta.url, which resolves as the location of the file as served by peersky://

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

builds Electron builds documentation Improvements or additions to documentation protocol New protocol to support ://

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants