creatFilter leaves filter id as a reason even for removed sync maps

[BerkliumBirb]

The problem I encountered is that when I use remote: false, offline: true template and call deleteSyncMapById on it, filter does remove it from it's internal representation. But it leaves actions in log with only reason being filter id.

As a result after page reload all actions are left in log and only that filter id saves these actions from being cleaned up later.

Is there any way to "skip" adding filter id as a reason for actions at all? Because it's not feasible to keep all possible filter ids to manually call removeReason for them on page load.

[BerkliumBirb]

I think the architectural problem here is that createFilter doesn't handle ungraceful interruptions at all. I can't really add onbeforeunload just to cleanup global filters. It might be a good idea to call log.removeReason(filterId) during filter setup to cleanup possibly ungracefully removed previous filter state.

[ai]

Can you try the next branch by using @logux/client@logux/client#next and @logux/core@logux/core#next?

[BerkliumBirb]

Yeah, that solved the issue. Are you able to publish that next version on npm with -alpha.0 or -next.0? I can't use github: dependencies in my project.

---

I also encountered a problem, that I don't understand how to solve other then doing nasty subscribe/unsubscribe stuff.

Code like this doesn't work in my case because filter.get() returns { isLoading: true } even after await filter.loading.

I can ask this question in a separate issue if want to.

[ai]

I will try to publish it when I will have time, but it needs to publish a lot of projects

Code like this doesn't work in my case because filter.get() returns { isLoading: true } even after await filter.loading

It should work. Open another issue with details.