learningequality / learningequality/studio

Stop using Vuex global content nodes state - “Trash” feature

Open
#3,447 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

DEV: frontend TAG: performance
Dominant language
Python
Stars
191
Forks
307
Avg merge
5d 6h
Merged PRs (30d)
10

Description

Summary

When using the trash modal while editing a channel

content nodes are added to contentNodesMap Vuex state

https://github.com/learningequality/studio/blob/d6f06c273469ae8ad202774d40accc69817284ae/contentcuration/contentcuration/frontend/channelEdit/vuex/contentNode/index.js#L15

Example:

https://github.com/learningequality/studio/blob/d6f06c273469ae8ad202774d40accc69817284ae/contentcuration/contentcuration/frontend/channelEdit/views/trash/TrashModal.vue#L210

The goal of this issue is to refactor the feature to not add/retrieve data to/from contentNodesMap and rather move towards using a more local state that will be cleared after a user stops using the feature.

Background

  • We accumulate content nodes data in Vuex contentNode/state from various Studio features of the channelEdit app and there is no mechanism for clearing them which causes memory leaks. This issue is part of a larger group of issues (see https://github.com/learningequality/studio/issues/3363) that aim to refactor problematic features away from using Vuex global state towards private in-components state or state that’s shared between more components but is cleared at some point and optimized performance-wise in general.
  • Ultimately, we want to get rid of globally stored content nodes data completely, however, this will be implemented incrementally, and therefore it’s fine to use mixed sources of data in the transition stage as long as all features continue working well from the user-point of view. Using composables is not required in all cases but is recommended as it has proven to be useful for state management across our products and it is flexible enough to allow us to keep using Vuex partially during the transition stage.

Acceptance criteria

  • No content nodes are added/retrieved to/from contentNodesMap when using the trash modal (applies to all sub-components if there are any)
  • The new implementation avoids the pitfalls of our current implementation that are described in the “Background” section and is optimized performance-wise overall

Blocked by

Blocking

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the Vuex content-node module at contentcuration/frontend/channelEdit/vuex/contentNode/index.js and the usage in channelEdit/views/trash/TrashModal.vue, then check blocked issue 3468. Trace all trash-modal sub-components that use contentNodesMap and define a local or otherwise temporary state approach. Done means the trash modal no longer adds or retrieves nodes through contentNodesMap while preserving its behavior and avoiding the stated memory and performance problems.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.