@tatiang in such a case I would try the delete row block before getting a new API response so the old and new responses don’t get blended together, As I’d like to make the app as dynamic as possible, or are there a better choice?
Have you given thought to using a Google sheet?
That changes dynamically as data is added/deleted and you can see it in real-time.
The point, that I’d like to make it as dynamic and personalized as possible, using a google sheet could make conflicts between different users as a single Google sheet is gonna be shared between them, but for local data source the customer experience will be personalized For each user.
Not too sure that I understand. The Google sheet does basically the same thing as the local datasource - allows you to CRUD data via the Thunkable app. I suggested the Google sheet as you indicated that weren’t seeing the updated data in the local datasource.
The Google sheet would serve as the datasource to the app and only be used by the admin to inspect data; your users would not have access to it. It is also easier to populate in the first instance as you can import from a CSV.
@steve_synopsis in the proposed apps different users would populate different sets of data upon an api response, and using a single Google sheet populated by different users would cause a conflict.
@drmina2007er0sjg So how are you going to handle it with the local datasource?
Sorry, I’m not sure what do you mean?
@tatiang there is a point I would like to understand, a local data source will be a part of the future device memory on which the proposed app will be installed, is that correct ?
Yes.
1 Like
Hi,
I was having a look back at the blocks and have realised that the generate JSON from object blocks are not needed. I tried it without then and it works fine and it makes sense as you do not need to be created JSON again from the object property value.
2 Likes
Ok that is better
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.