1

tl;博士：

我的类的方法名称与它扩展的类的同名冲突。我可以重命名我的班级，但我更喜欢不需要重大更改的解决方案。

背景

我发布了一个名为 的库lit-apollo，它导出class从LitElement. 用户应该使用我的类定义自己的customElements元素，然后这些元素可以使用 apollo graphql 获取数据，并使用 lit-html 进行渲染。有关简单示例，请参阅README。

问题

LitElement 的最新版本公开了一个名为 的实例方法update，它的实现可以选择性地覆盖以控制元素呈现的方式和时间。我的库还有一个update属性，它对应于updateApollo 突变构造函数的选项。

import gql from 'graphql-tag'
import { ApolloMutation, html } from 'lit-apollo/apollo-mutation'

const mutation = gql`
    mutation($id: ID!) {
      MyMutation(id: $id) {
        myResponse
      }
    }
`

const updateFunc = (cache, response) => 
  cache.writeData(doSomethingWith(cache, response))

class MutatingElement extends ApolloMutation {
  constructor() {
      this.mutation = mutation;
      this.variables = {id: "foo"};
      // here's where we break the LitElement contract
      this.update = updateFunc;
  }

  render() {
    return html`<div>${this.data.myResponse}</div>`
  }
}

customElements.define('mutating-element', MutatingElement)

这两种方法，显然是矛盾的。

问题

我知道我可以发布一个重大更改lit-apollo，将它自己的update方法重命名为onUpdate或类似的方法，但是我如何在不破坏我的类的 API 并因此需要主要版本的情况下解决这个问题？

我虽然检查第一个参数以查看它是否是 ApolloCache 的实例，然后super.update根据需要将 args 路由到，但我认为这会破坏 LitElement 合同，阻止用户实现他们自己的 LitElement 版本update

你会如何处理这种情况？

4

1 回答 1

1

我知道我可以对 进行重大更改lit-apollo，但是如何在不破坏类 API 的情况下解决这个问题？

你不能，真的。但这不是你的错：

LitElement的最新版本公开了一个名为的实例方法update

那是突破性的变化。因此，如果您将lit-element依赖项更新到最新版本，则还必须制作主要版本。为此重命名您的update方法是很自然的。或者，保留您的 API 并继续使用旧lit-element版本。

于 2018-09-23T08:29:17.273 回答