kennyfrc

Unfortunately I haven't thought much yet about interoperability with other web components libraries like lit. I imagined folks would choose just one web component library over the other.

That said, you can initialize reactive properties(1), but property bindings won't work if there's a parent LitElement (as my reactive properties need to be called with either a .value method or an .update method for getting and setting respectively).

As of the moment, what's possible is interop with other cami elements using a store, and in a future version, i'm considering a richer event system for external javascript code to listen to.

---

```

// define observable

this.count = this.observable(0);

// getting

this.count.value;

// setting

this.count.update(value => value + 1);

```

But it also has a redux-like pattern where you can dispatch actions and register reducers with far less ceremony:

```

// define store

const todoStore = createStore({ todos: [], });

// register reducer / producer

todoStore.register('add', (store, payload) => { store.todos.push(payload); });

// subscribe component to store

this.todos = this.subscribe(todoStore, 'todos');

// dispatch

this.dispatch("add", newTodo);

```

It looks like it’s mutating, but both the reducers and update() uses immer* under the hood, so we still respect immutability under the hood.

Cami supports redux devtools so you can use that for time-travel debugging too.

—-

It doesn’t support SSR as it aims to be backend-agnostic (i.e. you can use python/ruby/haskell, and you can copy+paste the Cami module with no build step and you can start using it).