|
1 | 1 | <div class="wrapper">
|
2 | 2 | <h1>Use cases</h1>
|
3 | 3 |
|
4 |
| - <p>Let's explore some of the use cases for this approach...</p> |
| 4 | + <p> |
| 5 | + Let's explore some of the use cases which can be solved using this |
| 6 | + library... |
| 7 | + </p> |
5 | 8 |
|
6 | 9 | <h2>Microfrontends style "sub-applications"</h2>
|
7 | 10 |
|
@@ -364,10 +367,66 @@ <h2>Microfrontends style "sub-applications"</h2>
|
364 | 367 | independently from release cycle of consumer applications?
|
365 | 368 | </blockquote>
|
366 | 369 |
|
| 370 | + <p> |
| 371 | + This is exactly what is enabled by this library! The "sub-application" |
| 372 | + element is released and deployed independently as a single file bundle which |
| 373 | + is then <strong>referenced ONLY by the url</strong> in the consumer apps. |
| 374 | + </p> |
| 375 | + |
| 376 | + <p> |
| 377 | + To make referencing easier, the bundle file name can always stay the same |
| 378 | + (for example <code>some-element.js</code> without any hash) for every |
| 379 | + version of the element. The cache busting is then handled with the help of |
| 380 | + <code>etag</code> which is transparently calculated based on the file |
| 381 | + content on the server. Learn more about |
| 382 | + <a |
| 383 | + href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag" |
| 384 | + target="_blank" |
| 385 | + >ETag</a |
| 386 | + > |
| 387 | + HTTP response headers. |
| 388 | + </p> |
| 389 | + |
| 390 | + <blockquote> |
| 391 | + We could still employ query params (or even file name versioning) in case we |
| 392 | + would like to have more granular control about which version of the element |
| 393 | + will be downloaded by the consumer appto facilitate stuff like A/B testing. |
| 394 | + Please note that this has to be implemented with corresponding support on |
| 395 | + the server side. |
| 396 | + </blockquote> |
| 397 | + |
367 | 398 | <h2>On-demand loading of a heavy 3rd party component</h2>
|
368 | 399 |
|
| 400 | + <p> |
| 401 | + Let's say we are building an Angular application and we are paying extra |
| 402 | + attention to architecture of the features making them nicely isolated and |
| 403 | + lazy loaded. The performance, maintainability and start up time of our |
| 404 | + application is great! |
| 405 | + </p> |
| 406 | + |
| 407 | + <p> |
| 408 | + Then comes in a new requirement to add possibility to inline edit every item |
| 409 | + of a large list using a powerful (but also very heavy) rich text editor. As |
| 410 | + a result the size and hence loading of that feature will suffer even though |
| 411 | + the editor is only displayed as a result of user interaction and never from |
| 412 | + the start. |
| 413 | + </p> |
| 414 | + |
| 415 | + <blockquote class="large"> |
| 416 | + Ability to seamlessly load element once it was rendered as a result of user |
| 417 | + interaction is exactly what can be achieved using |
| 418 | + <code>*axLazyElement</code> directive! |
| 419 | + </blockquote> |
| 420 | + |
| 421 | + <blockquote> |
| 422 | + Another possible solution to this problem could be by implementing custom |
| 423 | + component loader service using plain Angular. Unfortunately, currently (as |
| 424 | + of version <code>8.1.0</code>) such an approach is only possible using |
| 425 | + deprecated APIs and is pretty complex in itself... |
| 426 | + </blockquote> |
| 427 | + |
369 | 428 | <blockquote class="large">
|
370 |
| - Did you use this library for a different use case not mentioned in this |
| 429 | + Are you thinking about some different use case not mentioned in this |
371 | 430 | section? Please, let us know and open an
|
372 | 431 | <a href="" target="_blank">issue</a> or submit a
|
373 | 432 | <a href="" target="_blank">PR</a>
|
|
0 commit comments