New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rationalize frontend messages store #1091

Open
tiltec opened this Issue Aug 31, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@tiltec
Copy link
Member

tiltec commented Aug 31, 2018

The frontend messages store got a bit disorganized lately, with three vuex modules containing conversations and messages: conversations, currentThread and latestMessages.

  • conversations: wall messages, detail sidebar (but not threads)
  • currentThread: thread sidebar
  • latestMessages: messages popover and page, unreadCount for various bits around Karrot

Problems as of now:

  • data needs to be updated in multiple places
  • conversations module is tightly coupled to currentThread module
  • isUnread status is wrong for thread replies when no currentThread is selected

I guess at this stage it makes sense to rethink messages storage.

@nicksellen

This comment has been minimized.

Copy link
Member

nicksellen commented Aug 31, 2018

data needs to be updated in multiple places

I wouldn't consider this a problem, I think it's quite natural that some of the store module state is denormalized. I would like it if vuex gave an option to have global mutations when using namespaced modules (such that you can commit a change, and multiple modules can receive the mutation and update their state as appropriate) - which we could implement ourselves if it seems a good way forward.

conversations module is tightly coupled to currentThread module

The global mutations pattern could help with this too. An extension of the idea would be to slightly seperate "read" (getters) and "write" (actions) steps - so we might trigger all conversation-related actions in a conversations module (that does not keep (much) state), but let other modules receive the mutations in order to manage the state in a more specific way.

I would also consider it in the context of #1066 (<-- ooh 1066 is the date of the Battle of Hastings)

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Oct 8, 2018

I moved this into the "Current Development" milestone to have it as part of the Refactoring winter ;)

@tiltec tiltec referenced this issue Oct 8, 2018

Open

Unify and simplify vuex modules #1110

2 of 2 tasks complete

@tiltec tiltec self-assigned this Oct 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment