It looks like all pages are classed as Components.
While this may be a personal option (to use component or page), is this the growing trend and should we be following this for the sake of continuity?
On the same note, using Services or Providers as the container name. If they are essentially the same thing except for how you inject them, should we name all services - Providers?
in stencil you are working with plain components, like in angular
the āpageā stuff is something ionic 2-3 introduced, which will be vanished with ionic 4 with or without angular.
So ionic pages are angular components - so simple components at all - mixed up with some additional data for ionic routing via ionicpage decorator.
and providers are angular services
Maybe ionic team did not liked the wording if you check the meaning in programming languages or contexts.
So, I guess my confusion here is why is there a Page generator at all?
And even if there is, in order to be inline with future v4+ apps, should I be generating these Pages into a ācomponentsā folder?
I realize I have an option here. Just trying to be inline with the popular vote with new apps I am about to start.
Iāve just decided to even separate my modals in their own folder
I know it isnāt the angular standard but I found kind of misleading to have everything under components, specially when the app is more than 3 pages like I have
Iām guessing that it isnāt a technical problem since the cli doesnāt makes it mandatory to have all components and components
And in the worst case, Webstorm handle moving files super smoothly
So under src/app Iāve got
components
pages
modals
services
pipes
I guess I could have do something like the following too
Iām inline with you on this.
While I have not separated modals(yet), I would prefer to keep components/components:| separate.
So far I am getting the indication that it might be a wild west situation here.
If there is to be a page generator - might as well use it.
Currently I have a folder named providers - with a number of services in it.
If there is no consensus on this, I guess Iāll wing it and call the folder āservicesā - unless there is a case for something other than a service that might go in the āprovidersā folderā¦?
I know this is not of great importance and decisions can be undone with something like Webstorm as mentioned but would also like to solidify this, in my own apps at least.
@pwespi thanks, I never saw the core-update branch. That one uses a folder named Pages that looks to also contain modals, maybe (pop-over)
Did you try to use the CLI v4 to generate a provider? Does it create one in a folder called services or providers? I guess thatās maybe the added value
Except that, really, I have migrated my folder providers folder to services, so far I donāt see the added value
But I guess as long as we all use providers oder services we all speak about the same thing at least
When I last used the generator, it put providers in the app folder because I did not use it correctly as now we add the folder name in the command. So, really, it puts it into any folder you want. Although, I have not tried it with 4.0.2 yet. ( oops - now make that 4.0.3 )
I really do not see renaming all my services (ItemService.ts) to providers (ItemProvider.ts).
So I just installed CLI 4.0.3 and generated a page.
It no longer takes the prefix or folder name, so it put it directly into the app folder.
I could navigate to the pages folder and create the page there or, as I just tested use it like this: ionic g page pages/test
Which creates a folder named test in my pages folder.
There is no generate provider available. ionic g service whateverfolder/test works
I just reached last night to the same conclusion. Although modal pages are pages AND components, it made a lot of sense to group them inside a modals folder, since those arenāt pages you navigate to using the normal router way.
Also, despite pages being components, I found more clear to use the components folder only for reusable-component-tags. In my particular case, I have this structure:
componentes: reusable components
modals: pages to be used on modal dialogs
public: public pages (those you can navigate without authenticate yourself first)
private: secured pages (you need to authenticate to access anything under here)
services: common services
That is pretty much what I use except for the private/public separation.
For my purposes, those two designations are not always black and white due to multiple levels of admin access
and one-off access needs to a particular āprivateā page for special purposes.
I let my auth-guard and router handle that.
Yeah i should probably just make components - I guess my question really is, can I change what iāve put into a page, easily into a component? Sorry, Iām quite new to this. Happy to read any good articles you can point me to.
That sort of depends whatās in there. If it has navigation stuff like router outlets or tabs, probably would be best to rethink those. If itās just lists or items or forms, shouldnāt be much of a problem.
If you havenāt gone through it, I think the Tour of Heroes covers probably 90% of the questions newcomers to Angular app organization and framework idioms tend to have, including the ones they donāt know to ask before going down rabbit holes.