Jan

@felixhaeberle this will be one of my immediate next tasks and i allready started looking into it, first step split up the systems, second step fix possible memory issues with...

@felixhaeberle the full fix for this is the lazy loading lix feature, martin shared a loom today with the current progress on this front. the planned timeline is attached, please...

agree we should not leak reactivity details but not sure why a proxy is required or the right way to do this.

@samuelstroschein @jldec and me also had a quick talk about this issue. we are still not sure if it might make more sense to expose the functional core for non...

@samuelstroschein i assigned me too, as i am about to evaluate this from lix perspective next week.

@samuelstroschein i think i would prefer an api wihtout having to manually wrap the original objects eg. import { openRepo } from "@lix-js/svelte-client" const repo = openRepo(....) isntead of import...

the main open question is how we deal with synchronous vs async data. eg. its easy to expose branchname as a property as its always available ```js $: console.log(repo.branch) >>...

> > i think i would prefer an api wihtout having to manually wrap the original objects eg. > > Too risky as a day 1 choice. > > We...

> Btw I think this discussion can be closed. Agree @janfjohannes ? > > * we expose getter functions > > * we can't expose static props due to the...

> Please elaborate why the adapter hooking into an existing project pattern would not work. > > The current (and likely future API) of exposing some form of a subscribable...