我在一家使用 Ext-JS 开发产品的公司工作。该产品目前过度扩展了 Ext-JS 组件并覆盖了父级功能。这充其量使升级变得困难。我们保留了 Ext-JS，但正在研究以非混杂的方式使用它。似乎有两个阵营。在一个阵营中，成员们认为我们应该在 Ext-JS 之上编写一个抽象，以防我们决定在几年内改变框架，希望这样我们就不会被束缚。我个人认为这是一个愚蠢的目标，所以我参加了阵营第二。我的理由是 Ext-JS 团队已经花时间为 web 提出一个合理的抽象——他们在领域内解决这个问题，而我们只是试图实现一个很酷的产品。我想如果我们写一个抽象，它会假设为 Ext-JS。我看到我们在编写劣质抽象，它们的功能不那么强大，并且不会映射到 jQuery 世界(或任何其他框架)。关于正确的行动方案的意见？
最佳答案
我同意你的看法；我认为这是一个愚蠢的目标。原因如下:
最终(几年后)您可能不会更改框架。如果您不这样做，那么您将花费额外的时间和资源来添加一个不会给您带来任何好处的抽象层。它不仅无法完成您设定的目标(使您的选择多样化)，而且会增加您和您的团队成员需要维护的代码量。
您始终可以使用其他 Javascript 库对您的项目进行模块化，以满足 ExtJs 无法满足的任何需求。例如，如果您不喜欢 ExtJs 的图表实现，那么您可以包含 jQuery 并使用 jqPlot 等插件。
很难编写适用于当前和 future 库的抽象。您如何保证您的抽象能够承受当前库选择(ExtJs 等)或您将来喜欢的任何 future JS 库的变化。
只是几点思考。总的来说，我认为维护起来会很麻烦，所以我会选择一个多样化的库来满足您的大部分需求，然后在必要时添加较小的库。
关于javascript - 如何在野外使用 Ext-JS？摘掉还是不摘掉？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5339175/