Your content seems really interesting ! Still a bit high level for me right now, but i'll definitely get that pro member ship in a month time, just started a beginner course on ionic like yesterday, love your stuff though, keep it up man ! 👍👍
Thank you for this content. Some day, when the Dollar in Brazil come down to half of the current price, i expect to be will be able to buy your course (pro member) 🤣🤣🤣🤣 especialy for The TDD content, thats such a rare kind of content
As always, great video Josh!! My question is about architecture: some years ago the trend was to have a SharedModule with Modules (Browser, Ionic, Form, Material, ...), Components (in your case: UI dumb components in contrast to "Page" Smart components), Directives, Pipes, .... So you can import that SharedModule to your SmartComponent/Pages. Now, I see that you directly import those components from `shared` folder. Does it perform better? Has anything to do with nx shared library architecture? Thank you in advance.
This suits the Nx philosophy better, but it isn't an approach specific to Nx. A SharedModule is still certainly commonly used, but the idea of SCAMs (Single Component Angular Modules) is becoming more common. The downside of a SharedModule is that usually a whole bunch of stuff gets lumped in together there, and if you want one thing you have to import everything. With the SCAM approach, you only ever need to import exactly what you need, and especially in the context of an Nx project it makes it much easier to create reusable libraries.
@@JoshuaMorony that was what i figured. Thank you! Like other comment says, I'm interested in how to easy test or go around TDD. In my case, the problem is that I frequently I don't know how or what test before: template rendered components, loaded and processed data, controller functions, ... Anyway my idea is to test those parts or functions that will alert if another developer or me month later changes something that breaks indirect/whole component functionality.
@@MikelAingeru this is partly why I like TDD so much. It seems like the "hardcore" testing approach, but I think it makes things way easier if you are new to testing because it solves that problem of "I don't know what to test", because you write a test for whatever it is you are about to build. That still doesn't solve the "how'' part obviously, but at least it's much easier to learn how to do it when you already know what the "what" is. I think TDD also lends itself to the creation of tests that actually end up protecting your app from breaking.
Hi Josh ! What would change if you had to integrate nx with your nx-like architecture ? Is there a section in your module about migrating this project to a monorepo architecture ? Thanks
The Firebase API keys are configured in JS, so they're not secret (a client has to know the API key in order to interact with the services). It's just used to identify your project, the actual enforcement of access (e.g. security rules) happens on the Firebase servers.
Been really getting into your content recently, after a long break from angular / ionic. Are you planning any special offers for the elite course soon, or did I arrive back at a bad time? 😅
I likely won't do any discounts on Elite Ionic at least until I release another module on there. I am working on something new now for the beginner/intermediate level which will go on sale when it launches (even though it is beginner friendly there will still be a lot of the modern Angular concepts I often talk about)
Hey Josh! Great video as always. I'm curious to know what would you put in clients.store.ts? Is that data that would be shared in all the 'client-xxx' pages? In that case I assume you're using component-store instead of ngrx/store because the former is way less verbose. I usually to that as well but often ending up having a HUGE store.ts as all the updaters, effects, selects of multiple pages are in a single file, contrary to when I use ngrx/store as I'm splitting my xxx.actions(effects, reducer).ts files depending on the pages or feature.
Usually I would use ComponentStore for just one component, but if it makes sense then using it for an entire feature or even in root can work too. I think if you try to keep state local to one component, and then only if necessary share among multiple, ComponentStore can deal with quite a lot of complexity nicely, e.g. if you are using a shared ComponentStore, don't just use it as a catch-all - still keep individual ComponentStores for local component state, and only place shared state in the shared ComponentStore
I don't think there is a good answer for that question - although Angular does have properties that can make it desirable in an enterprise situation (and I guess the stereotype is Angular = Enterprise, React = everything else), primarily I would make decisions based on the team/talent available or other factors. In my view, the team is always going to make a way bigger impact on the outcome than the choice of any particular tech/framework.
@@JoshuaMorony thank you for your reply.. what if skills/knowledge is not a factor, and you are a solo programmer and you want to build a huge application, what would you choose?
@@axelbryancasauran5159 If we assume someone that has no prior skills with React or Angular, and your goal is to build a large application, then (acknowledging my bias for Angular) I think Angular would look like the more appealing of the two. Primarily because because of the strong architectural opinions that are baked into Angular - gives you more guard rails/clear path to follow than a React application would.
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
Please continue with these videos they have been a ton of help. There isn’t a lot of good content for Angular out there. Thanks so much!
Thanks for the tour 🔥
Your content seems really interesting ! Still a bit high level for me right now, but i'll definitely get that pro member ship in a month time, just started a beginner course on ionic like yesterday, love your stuff though, keep it up man ! 👍👍
Thanks! I do have some more beginner oriented stuff over on joshmorony.com and my older videos also cover more of the Ionic/Angular basics :)
Thank you for this content. Some day, when the Dollar in Brazil come down to half of the current price, i expect to be will be able to buy your course (pro member) 🤣🤣🤣🤣 especialy for The TDD content, thats such a rare kind of content
Why using ng container and not putting ngif directly in the component tag ?
As always, great video Josh!!
My question is about architecture: some years ago the trend was to have a SharedModule with Modules (Browser, Ionic, Form, Material, ...), Components (in your case: UI dumb components in contrast to "Page" Smart components), Directives, Pipes, .... So you can import that SharedModule to your SmartComponent/Pages. Now, I see that you directly import those components from `shared` folder. Does it perform better? Has anything to do with nx shared library architecture?
Thank you in advance.
This suits the Nx philosophy better, but it isn't an approach specific to Nx. A SharedModule is still certainly commonly used, but the idea of SCAMs (Single Component Angular Modules) is becoming more common. The downside of a SharedModule is that usually a whole bunch of stuff gets lumped in together there, and if you want one thing you have to import everything. With the SCAM approach, you only ever need to import exactly what you need, and especially in the context of an Nx project it makes it much easier to create reusable libraries.
@@JoshuaMorony that was what i figured. Thank you!
Like other comment says, I'm interested in how to easy test or go around TDD. In my case, the problem is that I frequently I don't know how or what test before: template rendered components, loaded and processed data, controller functions, ... Anyway my idea is to test those parts or functions that will alert if another developer or me month later changes something that breaks indirect/whole component functionality.
@@MikelAingeru this is partly why I like TDD so much. It seems like the "hardcore" testing approach, but I think it makes things way easier if you are new to testing because it solves that problem of "I don't know what to test", because you write a test for whatever it is you are about to build. That still doesn't solve the "how'' part obviously, but at least it's much easier to learn how to do it when you already know what the "what" is. I think TDD also lends itself to the creation of tests that actually end up protecting your app from breaking.
Hi Josh !
What would change if you had to integrate nx with your nx-like architecture ?
Is there a section in your module about migrating this project to a monorepo architecture ?
Thanks
Nice, maybe some practical tutorial about testing?
Would you find it useful if I did a detailed review of one of the testing scenarios in this app (e.g. an e2e test and the associated unit tests)?
@@JoshuaMorony Yes, would be great!
man you're so sick
love your videos
wish I had a senior like you in my Team
Our angular Project is one big mess 😫
should we be able to see your api keys?
The Firebase API keys are configured in JS, so they're not secret (a client has to know the API key in order to interact with the services). It's just used to identify your project, the actual enforcement of access (e.g. security rules) happens on the Firebase servers.
What to couchDB videos?
Been really getting into your content recently, after a long break from angular / ionic.
Are you planning any special offers for the elite course soon, or did I arrive back at a bad time? 😅
I likely won't do any discounts on Elite Ionic at least until I release another module on there. I am working on something new now for the beginner/intermediate level which will go on sale when it launches (even though it is beginner friendly there will still be a lot of the modern Angular concepts I often talk about)
Hey Josh! Great video as always.
I'm curious to know what would you put in clients.store.ts? Is that data that would be shared in all the 'client-xxx' pages? In that case I assume you're using component-store instead of ngrx/store because the former is way less verbose.
I usually to that as well but often ending up having a HUGE store.ts as all the updaters, effects, selects of multiple pages are in a single file, contrary to when I use ngrx/store as I'm splitting my xxx.actions(effects, reducer).ts files depending on the pages or feature.
Usually I would use ComponentStore for just one component, but if it makes sense then using it for an entire feature or even in root can work too. I think if you try to keep state local to one component, and then only if necessary share among multiple, ComponentStore can deal with quite a lot of complexity nicely, e.g. if you are using a shared ComponentStore, don't just use it as a catch-all - still keep individual ComponentStores for local component state, and only place shared state in the shared ComponentStore
Could you please upload this project on your github?
!Joshua Morony - for enterprise application like ERP what do you think fits to use Angular or React?
I don't think there is a good answer for that question - although Angular does have properties that can make it desirable in an enterprise situation (and I guess the stereotype is Angular = Enterprise, React = everything else), primarily I would make decisions based on the team/talent available or other factors. In my view, the team is always going to make a way bigger impact on the outcome than the choice of any particular tech/framework.
@@JoshuaMorony thank you for your reply.. what if skills/knowledge is not a factor, and you are a solo programmer and you want to build a huge application, what would you choose?
@@axelbryancasauran5159 If we assume someone that has no prior skills with React or Angular, and your goal is to build a large application, then (acknowledging my bias for Angular) I think Angular would look like the more appealing of the two. Primarily because because of the strong architectural opinions that are baked into Angular - gives you more guard rails/clear path to follow than a React application would.
@@JoshuaMorony sounds great! Angular then 😊🚀
speak properly. u should use how not what a professional angular project... dislike
you showed nothing