spiderspace: blocks

safe+serializable layout+content blocks with Svelte

work in progress: experimental

goals

• introduce and explain Spiderspace
• deploy Spiderspace and its repos to static GitHub Pages websites so it's fork-friendly
• in this repo, create patterns, components, and helpers around a serializable block data structure that renders as Svelte components for layout and content, that works well with a structured editor, and that can be safely used from untrusted sources

motivation

Spiderspace is a bunch of prototypes using a particular web software toolkit: Svelte, SvelteKit, and more. See the table above for the currently active repos.

If you find yourself intrigued by any particular prototype, visit the discussions here on spiderspace/blocks and the issues in the appropriate repos. You're also invited to propose more prototypes!

Spiderspace does not publish to any package registries. The projects here are meant to be extracted and published to registries by anyone who wishes, which could include you! The source code is all public domain so you may use it however you wish. (and also, note that any contributions you make will be licensed the same)

This repo's prototype explores data-driven rich text authoring and UI creation using the same data structure and rendering patterns. The goal is to support users authoring and sharing untrusted rich content and dynamic end-user-programmable UI in a structured editing WYSIWYG-like environment. Share your thoughts in the GitHub discussions!

design

The goal of this prototype is to create patterns, components, and helpers around a serializable block data structure that renders as Svelte components for layout and content.

• create layouts, spaces, and documents with a serializable JSON data structure that's safe to share with strangers
  • currently simpler than Svelte AST, though this is going to change to use SVAST
  • safe to share (e.g. sanitized style attributes and allowlisted domains when loading any URLs)
  • support both text input as well as structured editing (so the canonical representation is likely a JSON AST)
  • should it include dynamic data loading, like what JSON-LD provides with Activity Streams?
  • is Block the preferred word?

innards

very much a work in progress

• 📁 src
  • 📁 lib — SvelteKit $lib directory
    • 📁 app — modules and data specific to this app, not expected to be portable or exported
      • 🔷 blocks.ts — block data for the current layouts
    • 📁 ui — generic reusable frontend things that may be upstreamed to other libraries
      • 🔷 block.ts — block types
      • 🔷 block.test.ts — block sanitization tests
      • 🔶 BlockView.svelte — render block data
  • 📁 routes — SvelteKit frontend

todo

• use zod to parse for sanitization
• use codemirror6
• center on SVAST instead of the current simplified Block
• dynamic remote async data loading? at odds with SVAST? (e.g. following Activity Streams URLs)
• component children/slots? (really creeping into AST territory...)
• implement Fragment
• more direct manipulation
• views
  • 2d block view (add optional x/y properties or maybe location.x/y)
• authoring
  • include an "add block" button in devmode
  • delete blocks
  • edit blocks
  • sort/dragndrop blocks
  • generic collection actions
• parse per-component props, per-element attributes, and per-event params
• security
  • allowlist domains for src and href
  • somehow put governing handles on events
• async data resolution (JSON URIs for sharing/persistance)
• make all blocks responsive
• let the iframes request their layout dimensions
• hot swap block branches?
• sync Iframe header with navigation inside the iframe?

usage

# node >= 16.6
npm i
npm run dev
# or
gro dev # npm i -g @feltcoop/gro

build

npm run build
# or
gro build

deploy

npm run deploy
# or
gro deploy

credits 🐢_🐢🐢

Svelte ∙ SvelteKit ∙ Vite ∙ esbuild ∙ uvu ∙ TypeScript ∙ Gro ∙ Felt ∙ Prettier & more

license 🐦

public domain ⚘ The Unlicense