Once we’ve jailed Ember this way, any plugin can grab a specific version’s instance using the API: `const Ember = emberLibsPlugin.getEmber(‘v2.9’) `. Yes, it’s stupid, but it has exactly the effect we need. In all cases, each plugin is self-contained, can be independently developed, built, tested, and deployed, and uses Semver to communicate changes in its API. Back-end plugins that deal purely with data are written as C++ REST microservices, and front-end plugins that deal with presentation are written as Javascript client applications and run inside Chromium Embedded Framework, which we bundle alongside the client. Each plugin could be anything from a shared utility (like audio playback), to a single screen (like the splash art you see when you first launch the client), to a complex data flow (like patching the game).
Let’s take a moment to catch up on the overall architecture of the League client update.Īny given build of the League client is expressed as a list of units called plugins. If you see something you want to know more about, drop a comment and let us know! For now though, let’s dive in. I’m here to give a very broad overview of the most interesting parts of our UI architecture - we won’t get to cover every bolt and weld in this post alone, but we should get a good feel for the general shape of things. We’ve been fielding a lot of questions about how the updated client’s Javascript/HTML/CSS works, and there’s a huge amount to cover there. Hi! I’m Jules Glegg, a Software Architect working on the League client update.
0 kommentar(er)
