react-relay-offline: Allow offline execution of mutations that do not modify the store

I’ve just upgraded from 0.11.1 -> 1.0.2 (and upgraded Relay to v6 - I’ve also tried v7).

When I turn my connection off to test offline, on one screen I get this error TypeError: Cannot read property 'toJSON' of undefined from the OfflineFirstRelay file in relay-offline.

It comes from this line:

var sinkPublish = environment
                    .getStore()
                    .getSource()
                    ._sink.toJSON();

This only seems to happen on one screen, I have done some digging and can’t see specifically why this would error and other screens not. I can dive into this further, but just wanted to see if there was anything obvious I’ve missed in the upgrade.

My relay-offline library in my yarn.lock is at the right version "@wora/relay-offline@^2.0.4"

I have also followed your react-native example (e.g. I’ve added useRestore above my QueryRenderer).

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (9 by maintainers)

Commits related to this issue

Allow offline execution of mutations that do not modify the store issue https://github.com/morrys/react-relay-offline/issues/35 — committed to morrys/wora by morrys 4 years ago

Most upvoted comments

Good 😉

morrys on Jan 14, 2020

Amazing - thanks Lorenzo! I’ll hopefully be able to give this a go tomorrow.

On Sun, Jan 12, 2020 at 11:28 AM Lorenzo Di Giacomo < notifications@github.com> wrote:

Hi @matt-dalton https://github.com/matt-dalton, today I released version 1.1.0 https://github.com/morrys/react-relay-offline/releases/tag/v1.1.0, let me know if there are no problems so that I close the issue 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/morrys/react-relay-offline/issues/35?email_source=notifications&email_token=AFLUIUOQS53CWR2UWUKZRBLQ5L5G5A5CNFSM4KCL3UI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWXT5Y#issuecomment-573405687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFLUIUMSCWMDDCEUWX3IPKLQ5L5G5ANCNFSM4KCL3UIQ .

matt-dalton on Jan 12, 2020

these days I try to sketch its implementation and release it on the weekend 😃

morrys on Jan 6, 2020

Sure…it’s a very simple one, which matches your hypothesis:

createMutationPromise({
        mutation: graphql`
            mutation updateScreenViewedMutation($input: UpdateScreenViewedInput!) {
                updateScreenViewed(input: $input) {
                    me {
                        dateScreenViewed
                    }
                }
            }
        `,
    })

[createMutationPromise is just our wrapper for commitMutation]

As I said, we didn’t bother adding in an optimisticUpdate as dateScreenViewed presently does nothing in the UI. But can see it’s a bit pointless to return that value here.

matt-dalton on Jan 6, 2020