Show HN: Affinity.js – A simple view component library with store
with affinity you can make multiple apps (components eventually) and store (ala redux) - while a store can be shared through apps.
This started as a case study and as a small reusable code for creating self contained dom elements with functionality - during the time of development, ideas and inspiration came from angular, react and vuejs.
suggestions and feedback is mostly welcomed.
The interesting challenges were finding ways for these topics:
1. create a component lib using dom and js only, without any 3rd party .
2. producing semantic html in dom .
3. allow template micro syntax (using @click to bind an event listener) .
4. allow reusing custom elements within a component's template .
5. creating a simple store interface and auto connect it with a component to allow re render whenever the store changes .
any feedback and suggestions are welcomed
12 comments
[ 0.28 ms ] story [ 33.0 ms ] thread- few features were fun to think about - there were some challenges in making it work recursively for the template parsing.
- thinking of a simple api to use for the component also, making sure there are no memory leaks requires deep testing. - making auto render and connecting the store was a nice challenge
currently, i don't have a long term vision for it.
however, i do think of it of way to bootstrap small quick widgets in a page while sharing one or more stores. the aim is reusing the way i can create standalone dom elements fast and easy while using only es-latest code.
[1] https://mithril.js.org/
1. Parser prohibits literal "@click", there is no escape mechanism.
2. Only click, what about other DOM events?
3. Leaking: Event listeners not removed in destructor (your clean() function?)
4. No XSS protection, ow.
5. No tests, might want some.
6. Based on innerHTML assignment with nothing to guarantee valid HTML.
7. No error handling.
2. click was a poc - all events are added.
3. 'clean' is using "node.remove" ad removes any references to functions - so - no detached references are left then.
4. correct - not taken into consideration at the moment.
5. agree.
6. innerHTML is a valid assignment - the browser validates it.
7. to be discussed
1. What I mean is that <span>@code</span> becomes <span>data-af-click</span>.
2. Where? Not seeing them.
3. You're mistaken about event handler cleanup: https://dom.spec.whatwg.org/#dom-childnode-remove
6. My point here is that relying on strings is brittle. HTML builders, declarative APIs like JSX/React.createElement, and template-based approaches (where the template is a DOM node) are more robust.