“我的班级”的方法名称与其扩展的班级上的相同名称发生冲突。我可以重命名我的班级，但是我更喜欢不需要重大更改的解决方案。
我发布了一个名为lit-apollo的库，该库导出了一个从LitElement开始的https://%{namespace}.gitlab.io/-/%{project_name}/-/jobs/%{ref}/artifacts/htmlcov/index.html?job=%{job_name}。用户应在我的类中定义自己的class，然后这些元素可以将apollo graphql用于数据，并使用lit-html进行呈现。参见README以获得一个简单的示例。
LitElement的最新版本公开了一个名为customElements的实例方法，该实现可以选择重写以控制元素的渲染方式和时间。 我的库还具有一个update属性，该属性对应于update option of Apollo mutation constructors。
update这两种方法显然是矛盾的。
我知道我可以对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或类似的名称，但是在不中断类的情况下如何解决这个问题呢？ API，因此需要主要版本吗？
虽然我已经检查了第一个参数以查看它是否是ApolloCache的实例，然后根据需要将args路由到onUpdate，但是我认为这会破坏LitElement契约，从而阻止用户实现自己的契约LitElement的super.update
您将如何处理这种情况？
答案 0 :(得分：1)
我知道我可以对
lit-apollo进行重大更改，但是如何在不破坏类API的情况下解决此问题？
您不能，真的。但这不是你的错：
的实例方法。
LitElement的最新版本公开了一个名为update
那是重大的变化。因此，如果将lit-element依赖项更新为最新版本，则还必须制作一个主要版本。为此，重命名update方法是很自然的。另外，请保留您的API并继续使用旧的lit-element版本。