-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add Sync screen #241
Conversation
1572d25
to
d2f0952
Compare
There are some TODOs that I scattered in the PR in the earlier days of working on this. I haven't looked at them in a while but will revisit tomorrow to see if they're still relevant |
Can you rebase/merge from main? It will be easier to test once I can invite someone to a project |
d2f0952
to
2cf73e9
Compare
done! |
Were you able to make 2 devices sync? I am testing with 2 devices that are both on the same project and network and they are not discovering each other. My phone has this problem with sync in mapeo-mobile, so it could be my device. |
honestly haven't tried actually syncing yet (needed the invite stuff merged before I could test it). expecting there to be some issues that I need to resolve, so consider this PR "ready to review but probably needs lots of work based on real testing" 😅 as for your issue, are you talking about discovery when inviting or during sync? |
I was able to discover the other device and invite them to a project. But on the sync screen, both devices are saying "0 devices nearby" even when they are on the same wifi network |
ah that might be an issue in my implementation then. will need to look into it but thanks for noting it 👍 |
converting to a draft until I revisit this and test it out given the recent updates, which are relevant for this |
I did a quick code review (not a functionality review) and no glaring problems. I didn't go to deep into it though because it seems like there will some code changes when trying to make it work |
2cf73e9
to
2a086ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a small question and a few nitpicks.
src/frontend/hooks/useSyncState.ts
Outdated
isSubscribedInternal = true; | ||
project.$sync | ||
#onSyncState = (state: SyncState) => { | ||
console.log({from: 'listener', ...state}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: should we remove this?
console.log({from: 'listener', ...state}); |
.then(this.#onSyncState) | ||
.catch(e => { | ||
error = e; | ||
listeners.forEach(listener => listener()); | ||
this.#error = e; | ||
this.#notifyListeners(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do anything special if we've unsubscribed before this promise resolves? I imagine the following scenario:
#startSubscription
is called, kicking offthis.#project.$sync.getState()
.#stopSubscription
is called.- The
getState()
promise resolves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it's okay because resolving will eventually call the subscribed listeners (in #onSyncState
), but if #stopSubscription
is called it's because there are no more listeners, so it should result in a no-op.
that's my initial thinking, anyways
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm hoping this is a useful shared component for us moving forward. basically creates a layout that includes a fixed position "dock" at the bottom and a scrollable content area above it. this is to account for allowing dynamic content area size without needing to scroll down to the bottom of the view to see the content in the dock. the overflow from the content area gets clipped by the fixed dock area. usually this dock area contains big, actionable buttons, and we don't want these to get hidden due to being pushed by an overflowing content area
![image](https://private-user-images.githubusercontent.com/18542095/325308605-dbf065e9-c2d4-4669-9c3b-621f5ee16ac8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkyOTM3MzgsIm5iZiI6MTczOTI5MzQzOCwicGF0aCI6Ii8xODU0MjA5NS8zMjUzMDg2MDUtZGJmMDY1ZTktYzJkNC00NjY5LTljM2ItNjIxZjVlZTE2YWM4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjExVDE3MDM1OFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNkNjUzMGM1ODliMDY5MDA4MmY0ZTUxOGQ3NDc1ZDk1ZDk2ZjZiOGM3OGNlNzdkN2M3YzBiNTk1MjBkYmY0YjQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.LbVrardBzKBEwHctNUSJ0bsRziyhGt3-KPkG_e3D1Ko)
// TODO: Replace with proper check of being a part of a shared project | ||
if (data && data.length === 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
highlighting this, even though this needs to be addressed later due to core limitations
src/frontend/screens/Sync/index.tsx
Outdated
} | ||
|
||
export const SyncScreen = ({navigation}: NativeRootNavigationProps<'Sync'>) => { | ||
// TODO: Is this the right field to use? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can probably remove this?
// TODO: Is this the right field to use? | ||
const wifiStatus = useLocalDiscoveryState(state => state.wifiStatus); | ||
|
||
// TODO: Handle error case |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this something we can address in this PR, or should be leave it for later? not sure what the error state would look like (would it use the bottom sheet modal pattern?)
React.useEffect(() => { | ||
if (isSyncDone) { | ||
project.$sync.stop(); | ||
queryClient.invalidateQueries({queryKey: [OBSERVATION_KEY]}); | ||
} | ||
}, [isSyncDone, project, queryClient]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussed elsewhere but this check should probably be done when leaving the screen e.g. navigation.addListener('beforeRemove', ...)
48f51fb
to
47e827b
Compare
Closes #118
Intentional omissions/departures:
Important changes:
useSyncState()
hook because I was noticing stale closure issues with the implementation. using a class-based approach seemed easier to work with and easier to get working.useSyncProgress()
hook, derived from the same sync store instance asuseSyncState()
TODOs that may block merging:
use correct color for project icon in ProjectSyncDisplayfigure out what settings button in top right of ProjectSyncDisplay is supposed to dodecide if we want to suspend data sync when app is not focusedfigure out how to calculate progress based on sync statereview changes touseSyncState
hookPretty difficult to test the sync states right now, so previews are working with mocked situations: