Skip to content
generated from figureland/base

A modular Typescript toolkit for building minimal infinite canvas apps

License

Notifications You must be signed in to change notification settings

figureland/infinitykit

Repository files navigation

CI NPM

infinitykit is a toolkit for building infinite canvas apps and experimental map interfaces. This is work in progress software.

The aim of this project is to provide a highly modular box of primitives that you can put together in whatever app or framework you want. The core logic isn't dependent on the DOM, so it makes it simple to render and interact with canvases programmatically on servers, Web Workers, OffscreenCanvas and so on. It tries not to make any many assumptions about how you render your canvas or the shape of your data.

While size wasn't the main priority, infinitykit is pretty small. It checks in at 5.37 kB all in, minified and brotlied. It's written from scratch using only figure dependencies. For now, SuperJSON is also optionally a peer dependency, although the hope is that will be removed and replaced with something custom and more minimal in the future. You'll need that if you want to persist your canvas data to local storage.

If you want to build an amazing whiteboard or node/edge diagramming tool, head over to tldraw and xyflow. Those projects are like the Volvo to infinitykit's kit car project.

Thinking

  • This library is 'headless' meaning it doesn't make any assumptions about how or where you want to render your canvas. This comes from the frustration of working with popular React ecosystem components that had fallen out of date and into disrepair, but still had a great quality implementation if you peel back the layers of framework code. I found myself having to update whatever styling system that project used that has since gone out of fashion.
  • Perhaps it should just be a Web Component? I wish the story with Web Components was more simple – I agree with Tom MacWright on this one. On paper WCs are exactly intended for this sort of project, filling in the gaps with complex interactive components that are impossible to standardise. And yet... it still doesn't feel like the right approach.
  • Radix (and others) shows a different path. In particular I was really interested to see Melt UI's Builder API. This feels like the right approach for me: wrap all the logic and subscribe to updates, keeping your UI completely separate.

Scripts

Install

bun install

Test

bun test

Build

bun run build