Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To ensure that the bulk updates are efficient, a set of unique update strings is created and populated as the notifications are looped over to be rendered. Once all of the notifications have been looped over, the elements in this set are then added to an Array (which is a React state variable). This array is treated as a queue of pending updates to be made. Whenever the length of this array is updated, all the updates within the array are dispatched, and then the array is emptied.

For a more detailed look at how this was all implemented, you can see the PR here: https://github.com/LiteFarmOrg/LiteFarm/pull/2258

Adding New Record Types for Notifications

...

  1. The code has to be able to figure out what type of record needs to be updated from a notification. If the notification is associated with a standard record(e.g. tasks), then this should be stored under notification.ref.entity.type in the notification. In this scenario, nothing needs to be changed. If for some reason the type of record which needs to be updated is not in this form, you need to update the function getUpdateFromNotification to return an appropriate string given the structure of the ref for that notification use case.

  2. The code has to know what redux action (or more generally, any function function) to dispatch for each type of update. For tasks, this action is the getTasks() redux action, although this will change for every type of record which needs to be updated. In order to tell the code what type of redux action must be dispatched for a specific update type, all you need to do is update the dispatchUpdate function to handle the updateType. This updateType should be the string returned from getUpdateFromNotification.

If you want to see how these are implemented for task notifications, you can see the PR here: https://github.com/LiteFarmOrg/LiteFarm/pull/2258