How to Build Extensible Third‑Party JavaScript SDKs for App Invocation

Third‑Party JS

When developers want to add comments to a blog, building a full‑featured system is complex; using a third‑party JavaScript service like Disqus can provide commenting with just a few script tags. Third‑party JS are self‑contained scripts or plugins supplied by external parties, loaded from remote servers and often paired with a data‑management platform.

Third‑party JavaScript applications are self‑contained components, usually small scripts or plugins, that add functionality to web sites. They are typically provided by independent organizations or individuals, and their code and files come from remote web addresses.

These scripts let developers achieve goals at low cost while retaining data management capabilities. The article uses the “app‑invocation” (唤端) feature as an example to discuss product positioning, functional boundaries, and extensibility of third‑party JS.

Product Positioning

Before development, define target users and their needs. For an “app‑invocation” SDK, the target is third‑party developers who need a quick way to trigger native apps. Instead of hard‑coding app IDs, schemes, and fallback logic in each page, the strategy can be managed on a server and exposed via a small script:

<code>&lt;script src='xx.js' id='10001' /&gt;</code>

This approach reduces integration effort and centralizes configuration, though it may add latency while fetching the strategy.

Functional Boundaries

Start with stable core features and add complexity later. Prioritize stability and extensibility, and limit exposed options to avoid misuse. For the app‑invocation SDK, core functions include launching the app and allowing developers to provide custom failure callbacks. Data collection at key points (strategy fetch, invocation, failure) enables funnel analysis.

Illustration of the feature map:

Extensibility

Beyond configuration, extensibility can be achieved with aspects and plugins.

Aspect

Developers may need custom logic when app invocation fails. The SDK can expose a callback stack and allow registration of functions for the

evokeFailed

stage.

<code>class CallAppSDK {
  constructor() {
    this.config = {};
    // support custom aspect callbacks
    this.callBackStack = {
      evokeFailed: [] // array of failure callbacks
    };
  }
  // register aspect callback
  on(stage, callback) => {
    if (stage && this.callBackStack[stage] && Array.isArray(this.callBackStack[stage]) && typeof callback === 'function') {
      this.callBackStack[stage].push(callback);
    }
  }
  // launch app
  callApp() {
    evoke(this.config);
    getEvokeResult(this.config, this.callBackStack['evokeFailed']);
  }
}
function getEvokeResult(config, evokeFailedCallBack) {
  const { appName, timeout = 2000 } = config;
  setTimeout(() => {
    if (!isPageHidden()) {
      log('evoke fail', appName);
      if (Array.isArray(evokeFailedCallBack)) {
        evokeFailedCallBack.forEach(cb => {
          if (typeof cb === 'function') cb(config);
        });
      }
    }
  }, timeout);
}
// developer usage
callAppSDK.on('evokeFailed', config => {
  location.href = 'https://h5.m.taobao.com';
});
callAppSDK.callApp();</code>

Registering a failure callback lets developers inject custom behavior without modifying the core SDK.

Plugin

To keep the core lightweight, additional features such as a generic UI can be added via a plugin system.

<code>class CallAppSDK {
  constructor() {
    this.plugins = {};
  }
  usePlugin(plugin) {
    if (typeof plugin === 'function') plugin();
    else if (typeof plugin === 'object') this.register(plugin);
  }
  register(plugin) {
    const { name, exec } = plugin;
    if (name && typeof exec === 'function' && !this.plugins[name]) {
      this.plugins[name] = exec;
    }
  }
}
const showUIPlugin = {
  name: 'showUI',
  exec: () => {
    CallAppSDK.on('afterInit', config => {
      showUI(config);
    });
  }
};
callAppSDK && callAppSDK.usePlugin(showUIPlugin);
// developer usage
callAppSDK.plugins.showUI();</code>

This simple plugin mechanism decouples optional features from the core SDK, allowing dynamic extension based on server‑provided strategies.

Conclusion

The article shares personal insights on learning and applying third‑party JavaScript, using an app‑invocation SDK as a concrete example. Readers are invited to share their own understandings and point out any mistakes.

References

What is Aspect‑Oriented Programming (AOP)?: https://www.zhihu.com/question/24863332 Designing a JavaScript Plugin System: https://css-tricks.com/designing-a-javascript-plugin-system/