Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: The new views system #24

Closed
cosminonnet opened this issue Nov 28, 2013 · 6 comments
Closed

Question: The new views system #24

cosminonnet opened this issue Nov 28, 2013 · 6 comments

Comments

@cosminonnet
Copy link

Hi Tyler, thanks again for this generator!

I switched to the latest version today (1.0.1) and I noticed that the views are handled differently. In development, the "views" folder is under the "app" folder, but when I build the site, the "views" folder is placed at the same level as the "public" folder (aka dist). I don't really understand what is the benefit of doing this way, personally I find it a bit confusing (the same goes for the "heroku" target). Can you please tell me why did you considered moving the "views" folder up one level, maybe there's something I'm not seeing.

Secondly, I think having compatibility with "yo angular" was nice in the previous version. Now, with these changes, it's not possible to use this generator for creating routes, controllers, etc. and we have to use "yo angular-fullstack", which is a little longer :)

Cheers

@DaftMonk
Copy link
Member

I agree that it is a little confusing that compiled views are put in the root folder, but the reason for doing it was to keep a clean directory structure when you deploy to a server.

Typically you don't want to mix the views that the server will be rendering into the folder that you're serving assets from, at least not for production. So that's the reason the views folder is output separately when you build for production. A more clear build output would have been to copy the public folder, views folder, server/lib files all into a dist folder. However it seemed somewhat unnecessary at the time to copy the server files, since they don't have their own build process.

That said, even if I left the views folder in the public folder, it still would break the original angular-generators sub generators. The angular sub generators normally modify the index.html file that's in the app folder to append the new controllers/services/etc that are created.

However, using a server view engine requires moving the index.(html or jade) file into the views folder so that the server could serve it. This results in the angular generator no longer being able to find the index file to append any new files to it.

Finally, once I decided I needed to move the index file into the views folder, it didn't make sense to have all the angular partials mixed in with it, so that's the reason for moving those into their own sub-folder called partials.

Hope that helps explain things.

Edit: One other note, I'll look into if it would be possible to allow for an abbreviated reference to the generator with angular-fs so its easier to type

Edit 2: Unfortunately, it doesn't appear to be possible to abbreviate it with an alias.

@andrewstuart
Copy link
Member

Haha we could make a grunt task that abbreviates it. Grunt af:subgenerator.

@DaftMonk
Copy link
Member

DaftMonk commented Dec 3, 2013

Not a bad idea. It would cut the length of the command in half for most subgenerators.

grunt af:service
vs
yo angular-fullstack:service

@andrewstuart
Copy link
Member

Also a quick hacky bash workaround is this:

function af {
    yo angular-fullstack:$@
}

Then af service foo results in yo angular-fullstack:service foo.

Just throw it in your bash_profile or .bashrc and you're set.

@bcgov
Copy link

bcgov commented Dec 4, 2013

Hi Tyler,
I am new to node/express/yeoman/angular stack. I am able to create an app skeleton using angular-fs generator and I had this same question as why /views is outside of /dist. I am not sure I fully agree with your argument. If it's for compatibility with angular-generators maybe it's OK. I am not familiar with that generator so it doesn't make any difference to me anyway. But my understanding is that anything under /dist will be served by web server as is, i.e. they are assets. This way /dist can be ported to other non-node web servers easily. Because the file structure under /views is controlled by angular rather than by express and all express do is serving view files as is, I think it does fit into the definition of "asset" therefore should go under /dist.
Maybe I missed something such as what if view files rely on server-side template engine such as jade? If you feel it still should under root, then I think at least you can put /views to .gitignore because it's derivative.
Fred

@DaftMonk
Copy link
Member

DaftMonk commented Dec 5, 2013

I suppose it may not matter if jade views are in the public folder with the rest of the assets, since the routing system should handle anyone trying to look at the files themselves anyway. I just thought it seemed wrong to put jade templates into the public folder because they don't really qualify as assets, however in the case that someone generates a project with just plain html views, it may seem strange to not put the html files into the public folder.

Good point about .gitignore on the views folder, I think I'll do that for the time being. But I'm open to putting the views folder into dist if people don't have a problem with having jade views in the public folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants