Roadmap

[lemol]

I was using this plugin primarily for internal projects. After having contributions from the community I see it is necessary address many issues.

I propose having two big releases.

0.1.0

• Ensure typescript support

• Upgrade to apollo-client 2.5

1.0.0

• Improve documentation

• Rethink the local state management

• Write tests

• Refactor the code

If you are using this plugin (or plan to), please feel free to propose items in this roadmap.

[lemol]

Cc: @iwater @rmros @chj-damon @imcvampire

[rmros]

@lemol why rethink the local state mangement?
is this meaning you want change apollo client state management to other like mobx, redux?

[lemol]

@rmros the idea is to continue with apollo client state management.
By "rethink" I mean the way we are doing the local state with apollo client state. Personally I'm not comfortable with the way we are doing it.

Now after apollo-client 2.5 release I think we have opportunity to rethink and see what we really want.

[imcvampire]

Hi, what do you think about using apollo-boost or using its configuration to start https://www.apollographql.com/docs/react/advanced/boost-migration.html

[rmros]

@lemol you are using local state like this code in your example :

const GET_VISIBILITY_FILTER = gql`
  {
    page @client {
      __typename
      todosPage {
        visibilityFilter
      }
    }
  }
`;

why you are not comfortable with that?
please show me some example to understand your meaning
i want know what do you expect ? (example with some code)

[lemol]

@imcvampire, one of the goals I wanted for building umi-plugin-apollo is to make it completely customizable.

As of the official docs, apollo-boost is not fully customizable:

Apollo Boost is a great way to get started with Apollo Client quickly, but there are some advanced features it doesn’t support out of the box. If you’d like to use subscriptions, swap out the Apollo cache, or add an existing Apollo Link to your network stack that isn’t already included, you will have to set Apollo Client up manually.

Currently with this plugin we can customize almost anything using the options file https://github.com/lemol/umi-plugin-apollo#options-file

[lemol]

@rmros, I'm quite fine with the schema we are considering for representing the page state, nevertheless the mutations resolvers looks more complicated than necessary.

This is the example of toggleTodo mutation resolver:

    toggleTodo: (_, variables, { cache }) => {
      const id = `TodoItem:${variables.id}`;
      const fragment = gql`
        fragment completeTodo on TodoItem {
          completed
        }
      `;
      const todo = cache.readFragment({ fragment, id });
      const data = { ...todo, completed: !todo.completed };
      cache.writeData({ id, data });
      return null;
    },

We need this to just toggle a boolean value. Maybe we can find a pattern or idiom to address possible commons mutations.

[imcvampire]

@imcvampire, one of the goals I wanted for building umi-plugin-apollo is to make it completely customizable.

As of the official docs, apollo-boost is not fully customizable:

Apollo Boost is a great way to get started with Apollo Client quickly, but there are some advanced features it doesn’t support out of the box. If you’d like to use subscriptions, swap out the Apollo cache, or add an existing Apollo Link to your network stack that isn’t already included, you will have to set Apollo Client up manually.

Currently with this plugin we can customize almost anything using the options file https://github.com/lemol/umi-plugin-apollo#options-file

Yes. I understand that! But my idea is using the best practice (the configuration from applo boost https://www.apollographql.com/docs/react/advanced/boost-migration.html) as our default configuration

[lemol]

@imcvampire, looks great! Yes we can learn from ApolloBoost defaults and options.
I will come with a proposal (if you do not 😄 ).

[ncioj10]

Is there a timeline for the further releases?