A Question About Seeing Changes

[SubutaDan]

My Flutter app use offline-first-with-REST to manage a collection of items ("kokos"). The user's kokos are displayed in a Listview on a stateful widget screen. The user can navigate to a detail screen where they can add a new koko or edit or delete an existing koko. After any of these actions the detail screen closes and the list screen reloads, rebuilding the list.

When the list screen reloads and the list is rebuilt, the change (create, update or delete) that the user just performed is reflected in the newly rebuilt list. This is the result I want, but I am wondering whether it will work reliably. My thinking is that the mutating operation happens asynchronously and so may not occur before the list is rebuilt, in which case its result would not be visible. Is this a legitimate concern? Do I need to add some form of change notification to ensure that the list will be up to date?

Thanks very much.

[hortigado]

Hi, there are several methods that can be implemented, such as adding an effect on the modified item when loading or a shimmer effect; or as you mentioned with a toast notification.
But in order to do these, a problem arises that is already being discussed #393 . How could we know if the document was successfully modified on the server if this information cannot be obtained; locally it is not the case because this can be known. It is a feature that still needs to be worked on in the package.

One idea that occurs to me is to create a RespondBrick() variable in each class and brick lea has the power to modify it locally. And thus be able to have more information about the status of this document, but this idea would be yet to be implemented by brick

class RespondBrick {
  String? remoteRespond;
  bool? synced;

  RespondBrick({this.remoteRespond, this.synced});

  RespondBrick.fromJson(Map<String, dynamic> json) {
    remoteRespond = json['remote_respond'];
    synced = json['synced'];
  }

[tshedor]

It sounds like your list just needs to reflect the latest state, so it should be built using a stream from OfflineFirstRepository#subscribe.

I'm unclear if this is about managing server response and potential rejection. What would trigger a list rebuild if it wasn't a mutating action the user performed themselves?

[SubutaDan]

Thanks, Carlos. I think my question is simpler than what you are answering. I am asking whether relying on the rebuild of the list is guaranteed (or very, very likely) to show the change made in the detail screen. If rebuilding the list will (almost) always show the change then I don't think I need to make any changes. If it is not then I may be looking for some kind of state management solution and might ask for suggestions about how to detect data changes in brick. Does that make sense? Thanks again for your help.

-Dan

On 16 August 2024 13:19:39 GMT+09:00, Carlos Moises Arevalo ***@***.***> wrote: Hi, there are several methods that can be implemented, such as adding an effect on the modified item when loading or a shimmer effect; or as you mentioned with a toast notification. But in order to do these, a problem arises that is already being discussed #393 . How could we know if the document was successfully modified on the server if this information cannot be obtained locally, it is not the case because this can be known. It is a feature that still needs to be worked on in the package. One idea that occurs to me is to create a RespondBrick() variable in each class and brick lea has the power to modify it locally. And thus be able to have more information about the status of this document, but this idea would be yet to be implemented by brick ``` class RespondBrick { String? remoteRespond; bool? synced; RespondBrick({this.remoteRespond, this.synced}); RespondBrick.fromJson(Map<String, dynamic> json) { remoteRespond = json['remote_respond']; synced = json['synced']; } ``` -- Reply to this email directly or view it on GitHub: #400 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Japan: +81 70 911 52405 US: +1 704 380 9253 UK: +44 7875 599 430

[tshedor]

Brick is not designed to handle any state changes. #subscribe will notify when your query's result has changed. Based on your follow-up, I think this is a UI/state question and outside the scope of Brick.

[SubutaDan]

Thanks, Tim. No, this is not about managing server response and potential rejection. I am using Navigator .then(setState . . .) Or Navigator.replace to trigger the rebuilds of the list screen when the details screen closes. Although it is working so far, I guess this method is unreliable for showing the latest changes. I will investigate OfflineFirstRepository.subscribe Thanks again.

-Dan

On 16 August 2024 14:10:21 GMT+09:00, Tim Shedor ***@***.***> wrote: It sounds like your list just needs to reflect the latest state, so it should be built using a stream from [OfflineFirstRepository#subscribe](https://github.com/GetDutchie/brick/blob/main/packages/brick_offline_first/lib/src/offline_first_repository.dart). I'm unclear if this is about managing server response and potential rejection. What would trigger a list rebuild if it wasn't a mutating action the user performed themselves? -- Reply to this email directly or view it on GitHub: #400 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Japan: +81 70 911 52405 US: +1 704 380 9253 UK: +44 7875 599 430

[SubutaDan]

Hi @tshedor ,
Thanks for pointing me at the subscribe() method. I have started working with it and it seems to be just what I needed.
BTW, the comments in the code say that it works for upserts. I am glad to report that it seems to work for deletes too.
Unless you think I have missed something I suggest we close this ticket.
Thanks again.
-Dan

[tshedor]

@SubutaDan Good to know if works for deletes too. Glad you've got the right tools to help you out here, good luck