syncedCrud: LegendState will attempt to sync when waitFor is back to falsey

[hirvesh]

@jmeistrich - apologies for the issue spam I am creating - but I am battle-testing the syncedCrud plugin and came across another unexpected behavior. Consider this scenario:

1. waitFor resolves to false initially -> sync doesn't happen, no attempt to connect to my CRUD endpoints occurs and everything works offline (as expected).
2. waitFor now resolves to true -> sync starts to happen (as expected).
3. waitFor resolves back to false -> sync still tries to happen and CRUD endpoints are hit (not expected)

Is point 3 the expected behavior? 🤔

CleanShot.2024-11-08.at.21.10.14.mp4

[jmeistrich]

No it's great! Keep the issues coming! You're finding scenarios I hadn't thought of. I've just been really busy (gave a talk last night and doing a workshop next week) so I haven't had a chance to dive into them yet.

#3 is by design because I hadn't considered a scenario where it would revert back to false. I use that mainly for waiting for authentication or for dependent tables to load first. Can you tell me more about a scenario where waitFor would get set back to false and what would you expect to happen?

[hirvesh]

@jmeistrich - basically the app starts in an offline mode (unauthenticated).

Sync happens only if you are on a pro plan and authenticated, so if pro plan trial expires or pro plan is not renewed it needs to default back to not syncing checking the flag isPro.

Thank you for the awesome work! No pressure, just reporting what I find here 🫡

[zoltlabs]

You could add another check within the functions that checks for the pro plan eligibility. That's what I do, since those functions are async anyways.

[hirvesh]

@zoltlabs - that's what I currently do - if it's not eligible, I throw and return 403 forbidden - but it would be nice not to see a bunch of errors on the browser console with the sync plugin hitting my sync endpoints endlessly 😬