Currently, the localValue for this component gets reset to props.value. This is okay most times, but if the update of props.value takes a while(i.e. props.value is coming from the backend and we're pushing it to the backend and reloading), this doesn't update the UI until onUpdate finishes.
Added functionality to disable the edit/delete popover as well when using it as non-editable
Implementation Description
Changed the logic that forces localMessages to props.value if there is any discrepancy to become an effect, only to trigger when props.value changes.
Added nonEditable property to make the item non-editable, meaning the edit/delete functionality will not be there.
Moved the color setting of the chat out of isEditable into its own property didUserWriteMessage
Any new dependencies Introduced
N/A
How Has This Been Tested?
Storybook
PR Checklist:
[x] I have implemented all requirements? (see JIRA, project documentation).
[x] I am not affecting someone else's work, If I am, they are included as a reviewer.
[x] I have added relevant tests (unit, integration or regression).
[x] I have added comments to all the bits that are hard to follow.
[x] I have added/updated Documentation.
[x] I have updated the appropriate changelog with a line for my changes.
NOTE: There still seems to be an issue where if there are multiple changes(multiple messages sent) and the process to update is quite slow, there will be a lag behind actually getting the items committed(since the onUpdate fires multiple times for each change). Unfortunately, I don't know how to get around this, but I do know we have a loadingComponent added, which we can utilise on time-intensive requests.
Motivation and Context
Currently, the
localValue
for this component gets reset toprops.value
. This is okay most times, but if the update ofprops.value
takes a while(i.e.props.value
is coming from the backend and we're pushing it to the backend and reloading), this doesn't update the UI untilonUpdate
finishes.Added functionality to disable the edit/delete popover as well when using it as non-editable
Implementation Description
localMessages
toprops.value
if there is any discrepancy to become an effect, only to trigger whenprops.value
changes.didUserWriteMessage
Any new dependencies Introduced
N/A
How Has This Been Tested?
Storybook
PR Checklist:
Screenshots (if appropriate):
Before changes:
https://github.com/user-attachments/assets/53855fc2-d5b6-49ba-ab7e-52982ab2d8fa
After changes:
https://github.com/user-attachments/assets/9acaf4a8-1b9d-4655-8193-4b4f45f8f3b8
NOTE: There still seems to be an issue where if there are multiple changes(multiple messages sent) and the process to update is quite slow, there will be a lag behind actually getting the items committed(since the onUpdate fires multiple times for each change). Unfortunately, I don't know how to get around this, but I do know we have a
loadingComponent
added, which we can utilise on time-intensive requests.