@@JoshuaMorony Hi Josh, will your page generator create ionic pages in a library? When I try to create a page using the @nxtend/ionic-angular it creates the page in apps :/
thanks! I personally think pushing all app code to libraries is an overkill unless there is going to be a need to use the same app like features across multiple apps. Even then I can argue the dumb component shared ui setup would suffice (same as your earlier videos on this topic - which i like / agree with very much) . I am nowhere near as advanced as you are so may be i will have the aha moment later but for now that intermediate shared dumb ui set-up is it for me:) thanks for all the great work!
That's extremely interesting and helpful, Joshua! I'd love to see you continuing this to more advanced stuff, like incorporating NgRx with multiple apps etc! Great work!
Thank you Josh! I've been watching all of your vids and they're literally valuable and have a lot of info. Please make playlists and create them as small courses becuz every video I watch you link to another some vids and the chain is so long and not that well organized although your content and your way of explaining stuff is absolotely amazing. Thank you again brother 😘
I definitely could organise some videos into some playlists - my week to week vids don't really follow any particular pattern so there isn't really a solid logical order, but I could probably come up with something more followable
It is a awesome video. I have just started to use nx with ionic and it is great. Would definitely love more of this videos. The nxtend plug-in has moved but the new one works really well
Now that we have Angular standalone apps and standalone components (and Ionic standalone components), does it make sense to go further with the minimal app / shell idea? Since we don't have an AppModule or an AppRoutingModule anymore, we could move everything in `src/app` to the shell. Then we could have `main.ts` point to the routes within the shell. Any thoughts?
I have a question. The goal of NX is to share what can be use from different apps. So why sharing Home? And RouterModule? Every app would use their own route nah?
I just give a try to nx-monorepo for my Ionic apps (and maybe nodejs backend in the future) and one of the go-to approaches was to move the logic from app to lib(s). I'm not very comfortable with creating feature libs that only serve for one app feature, until now I see libs for shared logic like storage or auth services, or at most for a shared login UI + service/interceptor, and doubts arise when I want to give a try to ngrx/ngrs/Akita state management for App or feature, and don't know where to put it. But anyways thank you for this and previous nx videos. The other concerns that I have are the git management in monorepo (I don't see the git-flow like suitable anymore when you have multiple apps/libs in same repo, and for the moment I return to "master" trunk based approach).
Lib and app are overloaded terms in a monorepo. Libs are building blocks while apps are compilation targets and plumbers (imagine having a mobile web app, an electron app, a desktop web app, etc). Without feature libraries you'd have to copy/paste EVERY feature from app to app
Thanks for the comment! If you're getting value out of just using libraries for UI and Services that's great, you don't need to go "full Nx". Although using libraries should't be all that different to creating feature modules in a normal Angular app, it just lives in libraries instead. And as for Git, I would just do what I usually do: task branches that are merged back into the main branch. If anything, Nx should make code collaboration easier because the app will be much more modular and one bit of code is less likely to effect another bit of code.
I don't really see the point of moving everything to libraries to leave a blank app on top with only a shell import. It only creates more nesting of folders to me with a bunch of config files with it. The shell module of an app and its smart features won't be shared outside of the app, so why having a folder organization that does not represent the scope of its usage ? Maybe it has a purpose that i don't see but so far in my comprehension of Nx i found it really overkill. I'm really interested in using Nx though for all the features it provides out of the box.
The majority of my libs generally are not shared, which is why I organise my libs into folders like 'libs/app-one/' 'libs/app-two/' 'libs/shared/' - anything that is in the app-one or app-two folders are never intended to be shared (although it does make it easy to move them to the shared lib if I need to). There are other benefits to splitting up into libs (like caching) but I don't really care about that stuff personally, I do it for the organisation of it. And you could make the argument that some stuff could just live in the app itself rather than libs if you don't intend to share it, but personally I prefer the structure/organisation of architecting everything in the same way. Then I also have the benefit of being co-located inside of the libs folder (e.g. if I want to work on some feature of my 'mobile' app I don't have to worry about where in the repo it might be, as I will almost always just be working in the 'libs' folder after the initial app is set up). But of course, that's just my opinion!
Do we need this structure now that we have standalone component ? It would be nice to show how to structure properly in case of completly standalones procjects
I wonder if this working with the latest nx workspace? I had trouble to upgrade my old version to latest nx and ionic and can't find anything about it.
Yes absolutely, this structure could be used for many different apps not just front end or Angular apps, and where possible you would even be able to share libraries between front end and backend apps. Things like helper functions are easy enough to share but if you are using something like Nest for the backend and Angular for the front end there will likely be opportunities for reuse there as well.
this video solved my biiiig problem in ionic. thank you very much.🤗🤗 and now how can i set access permission to libraries source code for a team people?
hello, when I run the command for creating angular ionic app I am getting the following error: Cannot find module '@nrwl/angular/generators' Any idea how to resolve this? And, why am I getting this error?
Nice, thanks - yes, I'd like followups showing adding more pages and components and data access, and *testing* in this structure (a great advantage of the NX 'affected' awareness) ... another approach (which emphasizes cross-platform reuse of the libs) is to use the '@nstudio/xplat' package - it'd be instructive to see your use of that method :)
@@JoshuaMorony it's interesting, and I'm playing with it, but a bit irksome in that AFAICT their generators (and the structure under libs/xplat) don't seem to follow the NRWL best practice patterns. Still, interesting ...
When i run 'nx generate @nxtend/ionic-angular:application nx-ionic-mobile' command it said 'The "path" argument must be of type string, Received Undefined', anyone knows why?
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
Yooo! That's my plugin! 😄 Hope you enjoyed the experience, there's more updates coming soon.
Thanks for the plugin Devin! I was wondering if you would be open to a pull request for a page generator?
@@JoshuaMorony absolutely! It’s been something on my to do list forever but just never has gotten prioritized.
@@DevinShoemaker great :) hopefully I'll be able to put something together this weekend
@@JoshuaMorony Hi Josh, will your page generator create ionic pages in a library? When I try to create a page using the @nxtend/ionic-angular it creates the page in apps :/
thanks! I personally think pushing all app code to libraries is an overkill unless there is going to be a need to use the same app like features across multiple apps. Even then I can argue the dumb component shared ui setup would suffice (same as your earlier videos on this topic - which i like / agree with very much) . I am nowhere near as advanced as you are so may be i will have the aha moment later but for now that intermediate shared dumb ui set-up is it for me:) thanks for all the great work!
That's extremely interesting and helpful, Joshua!
I'd love to see you continuing this to more advanced stuff, like incorporating NgRx with multiple apps etc!
Great work!
I struggled through Ionic Nx App a while back refactoring my components but this makes it proper easy. Thanks again Josh for the great content
Bro, you should have millions of views and hundred thousands of likes.
Thanks for the nice video.
Thank you Josh! I've been watching all of your vids and they're literally valuable and have a lot of info. Please make playlists and create them as small courses becuz every video I watch you link to another some vids and the chain is so long and not that well organized although your content and your way of explaining stuff is absolotely amazing. Thank you again brother 😘
I definitely could organise some videos into some playlists - my week to week vids don't really follow any particular pattern so there isn't really a solid logical order, but I could probably come up with something more followable
@@JoshuaMorony Thank you brother I appreciate that
It is a awesome video. I have just started to use nx with ionic and it is great. Would definitely love more of this videos. The nxtend plug-in has moved but the new one works really well
Now that we have Angular standalone apps and standalone components (and Ionic standalone components), does it make sense to go further with the minimal app / shell idea? Since we don't have an AppModule or an AppRoutingModule anymore, we could move everything in `src/app` to the shell. Then we could have `main.ts` point to the routes within the shell. Any thoughts?
I have a question. The goal of NX is to share what can be use from different apps. So why sharing Home? And RouterModule? Every app would use their own route nah?
I just give a try to nx-monorepo for my Ionic apps (and maybe nodejs backend in the future) and one of the go-to approaches was to move the logic from app to lib(s). I'm not very comfortable with creating feature libs that only serve for one app feature, until now I see libs for shared logic like storage or auth services, or at most for a shared login UI + service/interceptor, and doubts arise when I want to give a try to ngrx/ngrs/Akita state management for App or feature, and don't know where to put it. But anyways thank you for this and previous nx videos. The other concerns that I have are the git management in monorepo (I don't see the git-flow like suitable anymore when you have multiple apps/libs in same repo, and for the moment I return to "master" trunk based approach).
Lib and app are overloaded terms in a monorepo. Libs are building blocks while apps are compilation targets and plumbers (imagine having a mobile web app, an electron app, a desktop web app, etc). Without feature libraries you'd have to copy/paste EVERY feature from app to app
Thanks for the comment! If you're getting value out of just using libraries for UI and Services that's great, you don't need to go "full Nx". Although using libraries should't be all that different to creating feature modules in a normal Angular app, it just lives in libraries instead. And as for Git, I would just do what I usually do: task branches that are merged back into the main branch. If anything, Nx should make code collaboration easier because the app will be much more modular and one bit of code is less likely to effect another bit of code.
I don't really see the point of moving everything to libraries to leave a blank app on top with only a shell import. It only creates more nesting of folders to me with a bunch of config files with it. The shell module of an app and its smart features won't be shared outside of the app, so why having a folder organization that does not represent the scope of its usage ? Maybe it has a purpose that i don't see but so far in my comprehension of Nx i found it really overkill. I'm really interested in using Nx though for all the features it provides out of the box.
The majority of my libs generally are not shared, which is why I organise my libs into folders like 'libs/app-one/' 'libs/app-two/' 'libs/shared/' - anything that is in the app-one or app-two folders are never intended to be shared (although it does make it easy to move them to the shared lib if I need to).
There are other benefits to splitting up into libs (like caching) but I don't really care about that stuff personally, I do it for the organisation of it. And you could make the argument that some stuff could just live in the app itself rather than libs if you don't intend to share it, but personally I prefer the structure/organisation of architecting everything in the same way. Then I also have the benefit of being co-located inside of the libs folder (e.g. if I want to work on some feature of my 'mobile' app I don't have to worry about where in the repo it might be, as I will almost always just be working in the 'libs' folder after the initial app is set up).
But of course, that's just my opinion!
Do we need this structure now that we have standalone component ? It would be nice to show how to structure properly in case of completly standalones procjects
I wonder if this working with the latest nx workspace? I had trouble to upgrade my old version to latest nx and ionic and can't find anything about it.
am getting this error when generating an ionic application => > NX (0 , workspaces_1.buildWorkspaceConfigurationFromGlobs) is not a function
you might want to include --force when installing it.
What's the purpose of moving the mobile routing file into libs? It seems not clear to me how it would be shared across the apps.
Very good video! Curious to know if this could be used to re-use backend and frontend libraries?
Yes absolutely, this structure could be used for many different apps not just front end or Angular apps, and where possible you would even be able to share libraries between front end and backend apps. Things like helper functions are easy enough to share but if you are using something like Nest for the backend and Angular for the front end there will likely be opportunities for reuse there as well.
How do things like `ionic cordova prepare ` work with this?
Hello @Joshua.
Can you please at a look of this question. Getting trouble to creating ionic-angular app into workspace.
this video solved my biiiig problem in ionic. thank you very much.🤗🤗 and now how can i set access permission to libraries source code for a team people?
hello, when I run the command for creating angular ionic app I am getting the following error:
Cannot find module '@nrwl/angular/generators'
Any idea how to resolve this? And, why am I getting this error?
If you've generated a blank workspace and not an Angular specific one, make sure to install the @nrwl/angular package
Thanks. :) I thought that nx adds angular by default.
Would this structure work with React/NextJS?
Please do make a follow 🔥😅
Nice, thanks - yes, I'd like followups showing adding more pages and components and data access, and *testing* in this structure (a great advantage of the NX 'affected' awareness) ... another approach (which emphasizes cross-platform reuse of the libs) is to use the '@nstudio/xplat' package - it'd be instructive to see your use of that method :)
xplat is not something I've come across, it looks like an interesting one to investigate!
@@JoshuaMorony it's interesting, and I'm playing with it, but a bit irksome in that AFAICT their generators (and the structure under libs/xplat) don't seem to follow the NRWL best practice patterns. Still, interesting ...
When i run 'nx generate @nxtend/ionic-angular:application nx-ionic-mobile' command it said 'The "path" argument must be of type string, Received Undefined', anyone knows why?
Same here