[Question] Difference between "architecture style"?

Dear @NathanWalker ,

thank you for this wonderful add-on to nrwl/nx to allow using ìonic within the nrwl scope! Further, i would like to thank you for your time invested in migrating xplat to the latest angular version.

In the issue dealing with the ionic 5 angular 9 migration, we discussed that a lot of problems arise from using the xplat supporting architecture ( https://github.com/nstudio/xplat/issues/180 ).

What exactly is the xplat supporting architecture in this context? And what is the difference to the “regular architecture”?

---

Regular Architecture

• Just a plain ionic 5 application with everything in the /apps folder.

xplat Architecture

• There is - more or less - an “empty” /apps project that includes stuff from the /libs folder.
• Further, the /libs folder now contains folders for ui, feat, and so on…

---

Are there any other differences than just the “folder structure”? Because i would like to use my own structure in the libs folder. My nrwl/nx workspace already contains a libs folder with a lot of different sub-folders and modules. Therefore, i cannot use the xplat supporting architecture, right?

All the best and thank you very much for your time answering this question!

[NathanWalker]

@johannesschobel always a great question. This explains the reason for it fairly well: https://nstudio.io/xplat/fundamentals/architecture

But let me expand on a few things with a few questions:

• If you build and deploy an Ionic app and in the future your company wants to deploy another Ionic app internally for different purpose but want it to generally have same vibe/style. You want to reuse a lot of the styles (css or scss), what is your plan on reusing a lot of scss/css work you did for that app and use as a baseline in another Ionic app which would speed up development by just allowing you to theme the other app on top of what you already did? Would the plan be copy/paste and/or duplication of styling work into the other app in the workspace or perhaps publish various features or styles as a private npm package you would link in to reuse? And beyond that what would your plan be on keeping maintenance costs down in maintaining those 2 apps now vs. just the one? This is largely what xplat layer including libs/scss and xplat/ionic/scss can you help you prepare for today.

• Let’s say in a year your company decides it wants and maybe needs to deploy a desktop Electron app. You and your team invested a lot of time in building your Ionic app and would prefer to not retrofit everything to deal with Electron specifics. What would your plan be to deal with such a request efficiently and without pain? Given the common case focus was solely on just Ionic development and not thinking about future needs which ended up coupling a lot of Ionic behavior into low level core services in your workspace? This is largely what xplat layer including libs/features for baseline TypeScript that is platform agnostic and can be shared anywhere as well as xplat/ionic which is specific for Ionic only is for which can help start with good separation of platform concerns early.

• Consider the above but this time it’s iOS/Android native with something like NativeScript? How could you help future proof some of the workspace today to help deal with the unforeseen?

This is largely what the xplat layer is about in addition to the baseline set added to libs. It’s intended to be built on top of and around but attempts to imply a consistent approach to various cross platform needs (needs that are often not known today but could come up in future). By preparing the codebase with common denominator services like WindowService and a baseline BaseComponent which bakes in a consistent way to handle subscription teardown’s throughout anything built in the codebase it helps prepare from the beginning several setups that can ease some of that pain. For example WindowService can help bake in an approach to handling global window in ways that often cause quite a bit of pain when comes to adding server side rendering at a later time and/or even NativeScript.

Given the new internal Nx plugin structure that was introduced for plugins (mentioned here: https://nx.dev/angular/guides/nx-plugin) we’ve been looking into whether that structure would solve the needs that we have found for our own client projects. There’s possibility in future we could explore publishing some of the tools for that structure as an alternate route.

Hope that makes sense.

[NathanWalker]

Thanks @phillipplum that helps explain - When creating app’s without xplat architecture and plan to use purely Nx lib’s yes you are going a more manual route and do have to configure your tsconfig appropriately for those cases. We could look into automatically updating the Ionic app’s tsconfig in case of pure Nx lib creation. Sounds like that could help.