Recommendations on multi-platform dev

[NathanWalker]

I want to ensure all of those who come across this seed and/or are using it currently are successful in their multi-platform goals. I welcome and introduce you to a natural and exciting evolution:

If you are using this seed and experiencing frustrations, I would highly recommend looking at Nx from Nrwl. It provides a setup which will make your development with multiple platforms and sharing code pleasant with less overhead. If you are currently working in this seed you can likely drop your code in without much hassle. Instead of using .tns.html/.tns.ts files (for {N} views - don't worry, you can use everything you have already done!), use abstract base classes in shared libs which are extended by their decorated counterparts in your targeted apps. Please take a look at these starting videos: https://egghead.io/playlists/use-nativescript-with-nx-from-nrwl-161bd3e2

The setup and videos will help get you started with ngrx 4, latest/greatest Angular and NativeScript versions out of the box.

More helpful guidance around multi-platform development with Nx will be out this fall/winter covering Electron integration, advanced code sharing techniques, testing, webpack/Aot, CI integration and deployment.

With Nx, you can have many apps which all share a combination of many libs.

Example

Let's say our Nx workspace is called my-company.

Here's an example of a base abstract class which is shared with a target web and mobile NativeScript app for maximum code reuse:

libs: @my-company/shared

• libs/shared/components/nav.base-component.ts

export abstract class NavBaseComponent {
  public items = [
    { name: 'Home', path: '/home' },
    { name: 'About', path: '/about' }
  ];
}

• libs/shared/index.ts:

export * from './components/nav.base-component';

apps: NativeScript mobile app

• apps/mobile/app/nav.component.ts:

import { NavBaseComponent } from '@my-company/shared';

@Component({
  selector: 'ns-nav',
  template: `
  <StackLayout orientation="horizontal">
    <Button *ngFor="let item of items" [text]="item.name" [nsRouterLink]="[item.path]"></Button>
  </StackLayout>
  `
})
export class NavComponent extends NavBaseComponent {}

apps: Web app

• apps/web/src/app/nav.component.ts:

import { NavBaseComponent } from '@my-company/shared';

@Component({
  selector: 'app-nav',
  template: `
  <nav>
    <a *ngFor="let item of items" [routerLink]="[item.path]">{{item.name}}</a>
  </nav>
  `
})
export class NavComponent extends NavBaseComponent {}

[exeleon]

Hi @NathanWalker, Are you planning to stop supporting this seed? All this work is awesome, I consider the only ones topics to improve are AOT, webpack bundle, and lazy load for {N}.

[NathanWalker]

Hi @exeleon thank you for the input 👍

I have often longed for far greater simplicity in build tooling, more intuitive out of box extensibility pathways and more elegant platform separation with less danger of pitfalls. The Nx direction is where I am putting all my energy at moment in regards to this. At the moment I don't plan to extend this seed any further from where it is. It stands as one way to achieve multi-platform in a monorepo and I'd leave it up to those who find it to evaluate on their own. However I feel a responsibility to leave my impressions and thoughts after working in the space for over 2 years now. The helpful guides on Nx and more to come will prove to be the culmination of a lot of those thoughts and desires.

The topics you mention are some of the reasons I would probably not recommend continuing with the seed as it exists today. The webpack/AoT bundling with {N} is best served by having clear separation in decorated counterparts (not sharing a @Component decorated class) but rather works more effectively and reliably when maximizing code reuse through abstract base classes. The direction of the seed in this regard started with the hopes and dreams that custom component decorators would be supported with AoT compilation however that has not come to fruition. Please read this article: http://angularjs.blogspot.com/2016/03/code-reuse-in-angular-2-native-mobile.html for more information on the original hopes. It may still become a reality in the future and if it did I would return to continue on the direction of this seed.

At this point in time, sharing code which is intended to be compatible with all aspects of AoT compilation are served better by an abstract class approach as mentioned above.

I should mention that the videos shared regarding Nx offer a {N} app template which offers lazy loading out of the box for {N}, fully AoT compatible production webpack configuration with parallelization when uglifying which are the top topics you mention :)

I'd love to hear other's thoughts but that's where I'm at and feel a necessity to state it clearly.

[rernens]

@NathanWalker

Hi Nathan, I am using your seed for quite a while now and in several application and love it. Nevertheless, from a productivity standpoint during development cycles, I have been looking at what webpack with hmr brings to the plate for quite some time.

As you I am excited by Angular 5, Ngrx v4, Nx and now angular-ci given what Nx brings to the table for large application development.

Nevertheless, I must admit that I am a little bit lost when you write in your statement above that « If you are currently working in this seed you can likely drop your code in without much hassle ».

Conventions used are drastically different and I am wondering if simply dropping the code of an existing app and adjusting path will be sufficient to make it work.

I will try but would love to hear from you what you believe are the steps to follow to be succeed.

Thanks in advance

[NathanWalker]

@rernens I am happy to hear you are having success and enjoying it. Usually dropping the code in and adjusting the path should be sufficient in majority of cases as well as adjusting for abstract base class as mentioned above when moving away from .tns.html files.

If you could provide an example of something in your existing app that you might be curious about how to drop in, please let me know and I'll try my best to help guide you.

[rernens]

@NathanWalker

Hi

I have been successful at moving my project to Angular-cli and NX.

I followed the step by step guide that I found

https://github.com/angular/angular-cli/wiki/stories-moving-into-the-cli

making additional changes to cope with the way environment dependencies are handled in angular-cli vs your seed.

had some hard time to address fonts dependencies and found out that they needed to be stored in the asset folder to be used in url() or relative path would not work.

I still have to find a way to integrate index.html file changes based on build .

But apart from that everything works like a charm including hmr and aot.

Thanks

[kevincam3]

@NathanWalker is there any tutorial for how to do what you've done here with the 3: Angular, Electron & Nativescript using Nx Workspace(s)?

[NathanWalker]

I’ll be doing more with Electron and Nx in the new year but nothing formalized yet.

[amirtoole]

@rernens this is extremely late, but you don't actually have to store all static files (i.e. fonts) in an assets folder. .angular-cli.json is quite versatile and supports adding assets from any folder and even allows for them to be outputted anywhere you'd like (during build or at runtime). Here's an example:

      "assets": [
        "assets",
        "favicon.ico",
        { "glob": "**/*", "input": "../node_modules/@bower_components/", "output": "./assets/" }

You could change the input to only be .woff* for example.

As for different environments, leveraging environment is trivial for *.ts files. For index.html I followed the example here: https://github.com/angular/angular-cli/issues/4451 Arguably not as nice as what this seed provides for html templating, but does the trick for Analytics, etc.

Cheers