Chelonia in SW

[corrideat]

No description provided.

[corrideat]

Tests currently passing:

• signup-and-login.spec.js

For the non-passing tests, a common theme seems to be that document is undefined. I believe this to be related to DOMPurify, and the best solution seems to be removing it from contracts and the service worker.

Other things that are broken, but which should be easier to fix:

• Attachments

[cypress]

group-income    Run #3379

Run Properties:   Passed #3379  •  5db201867e ℹ️: Merge 74b2dfa934cc1b396de829d72edfdee73deb751f into 3b142e94445de8ab49b435e8d4bd...

Project	group-income
Branch Review	feature/chelonia-in-service-worker
Run status	Passed #3379
Run duration	10m 45s
Commit	5db201867e ℹ️: Merge 74b2dfa934cc1b396de829d72edfdee73deb751f into 3b142e94445de8ab49b435e8d4bd...
Committer	Ricardo Iván Vieitez Parra
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	10
Skipped	0
Passing	111
View all changes introduced in this branch ↗︎

[taoeffect]

What is preventing us from moving the getter definitions into a file that is shared by the frontend and the SW?

That would be much preferable to this.

[corrideat]

Chatroom getters are a Vuex module, which are harder to emulate without Vuex because of state partitioning. In addition, those getters rely on currentGroupId and currentChatroomId which can't be used in contracts.

[taoeffect]

Is there nothing creative that's possible here? We can't define getters in a way that has them referring to the "the chatroom that corresponds to this state"?

i.e. "state paritioned getters" ala gettersProxy? (see bottom of chelonia.js)

[corrideat]

the chatroom that corresponds to this state

How would that even be possible the way getters are defined? I don't really see an issue with the lines highlighted, and I'm not even sure why we'd need a getter that returns a single property.

But going to the definition:

  chatRoomAttributes (state, getters) {
    return getters.currentChatRoomState.attributes || {}
  },

Sure, in this instance state corresponds to getters.currentChatRoomState, but I don't see how generically we can know what getters.currentChatRoomState should be (generically). In the app, it works because (remember this is a global getter) there is a currentChatRoomId. In contracts it works, because currentChatRoomState can be defined to return 'state'. In the SW, the situation is analogous to the app, but there's no currentChatRoomId.

Now, this could maybe work by having a getter that takes the contractID as a function parameter, but this requires refactoring and adds complexity. I also think such getters that are simply accessors should be avoided, as they increase code line count and complexity for no benefit.

[corrideat]

Thinking about it, another solution along the lines of what you suggested could be something like:

const getters = sbp('chelonia/contract/getters', 'gi.contracts/chatroom', state)
getters.currentChatRoomState

But honestly, for simple accessors such as these I don't see the benefit of adding this complexity. This also adds two other factors:

1. If the getters are hardcoded (as in, statically imported), it increases bundle size
2. If the getters are dynamic, they'll probably need to be async (in case the contract isn't loaded) and because of sandboxing (maybe).

[taoeffect]

@corrideat would it be possible to instantiate dynamically a new batch of getters where getters. currentChatRoomState returns a specific contract state in the SW using some sort of factory function?

I also think such getters that are simply accessors should be avoided, as they increase code line count and complexity for no benefit.

Getters are very important, as they solve a lot of DRY related problems. By using getters we can ensure that the way that data is accessed everywhere will have consistent return values (e.g. because it uses tricks like || {} etc.). Whereas those considerations would have to be thought of each time you access state data directly.

[taoeffect]

const getters = sbp('chelonia/contract/getters', 'gi.contracts/chatroom', state)

Yeah, that's a great idea!

I'd make one slight modification: instead of passing in state, passing in contractID:

const getters = sbp('chelonia/contract/getters', contractID)

(EDIT: I don't think you need to pass in the name, that can be retrieved using contractID if needed)

Then yeah, at least we could reuse the contract getters that are already defined in the contracts!

[corrideat]

Update based on today's conversation: we could use getters synchronously by importing the contract getters from this actions file. However, it'd have the downside of being 'statically hardcoded' based on whatever version is imported at build time and will increase bundle size. Doing it via Chelonia is potentially possible, but it'd need to be async in case the contract isn't cached and need to be loading and also maybe because of sandboxing.

[taoeffect]

Is it possible to keep the getter?

[corrideat]

The reason that the getter isn't being used here is that although I added a wrapper for root getters, these are Vuex modules, which work a bit differently due to state partitioning. At the time, the separate state keys being used by the module weren't there. Now they are, and it would be feasible to similarly have this work.

While I think that in this instance it'd be possible to use a getter, many getters are written to rely on curentXXXId, which is problematic in the SW.

[taoeffect]

After signing up a new user, I got the last two errors:

service-worker.js:193:

Note: this happened twice in FFDev, once for u1, and once for u2 when joining using invite link.

[taoeffect]

I'm also not hearing notification sounds upon @mention. Did you merge latest master that fixed this?

[taoeffect]

In Safari, u3 joined, and u2 (in FFDev) made a proposal, then u3 switched form Chat to Dashboard to see proposal, then u1 approved proposal (in FFDev), then u3 (in Safari) switched back to Chatroom:

[corrideat]

After signing up a new user, I got the last two errors:

I need some more background on what exactly you were doing (e.g., what you were doing before). The mismatch error indicates that the event received is for the wrong identity contract. For the pubsub error, I don't need additional information at this point.

I'm also not hearing notification sounds upon @mention. Did you merge latest master that fixed this?

Presumably not. I've just merged master.

In Safari, u3 joined, and u2 (in FFDev) made a proposal, then u3 switched form Chat to Dashboard to see proposal, then u1 approved proposal (in FFDev), then u3 (in Safari) switched back to Chatroom:

I see. This looks like an issue with structuredClone somewhere. I don't have Safari so testing this might be challenging if it's a Safari-only issue.