Skip to content

Refactors ThreadActions: Api call moved to parent component.

Rafael requested to merge feature/refactor-thread-actions into master

Closes #878 (closed).

What does this MR do?

The api calls where made in the child component, but the data was passed in both directions from child and to child. From an architecture point of view, it was refactored so that the child is only responsible for displaying, but not for logic parts (api call).

How confident are you it won't break things if deployed?

Did not change much, moved only some functionality between two files.

Links to related issues

Any relevant links (issues, documentation, slack discussions).

How to test

Steps a reviewer can take to verify that this MR does what it says it does e.g.

  1. Checkout branch locally
  2. Login as foodsaver
  3. Open a thread (forum)
  4. Toggle bell, email and stickyness.

Screenshots (if applicable)

Any relevant screenshots if this is a design / frontend change

Checklist

  • added a test, or explain why one is not needed/possible...
  • no unrelated changes
  • asked someone for a code review
  • joined #foodsharing-beta channel at https://slackin.yunity.org
  • added an entry to CHANGELOG.md (description, merge request link, username(s))
  • Once your MR has been merged, you are responsible to update the #foodsharing-beta Slack channel about what has been changed here. They will test your work in different browsers, roles or other settings
Edited by Rafael

Merge request reports