Phoenix: Provide --no-html (or --api) on phoenix.new

[josevalim]

[stevedomin]

I'm fairly keen on tackling this one if no one is on it yet

[josevalim]

Please go ahead!

[railsmechanic]

I am interested in such an option, too.

[jadercorrea]

That's really a nice option to have. :+1:

[chrismccord]

:+1: to --api

[Tica2]

:+1: to --api

[railsmechanic]

:+1: to --api

[josevalim]

@chrismccord so the reason I am worried about --api is that folks could argue it should not include channels.

[evax]

What about finer grained control on what's to be included or not, e.g. --no-channels, --no-html?

[lexmag]

:+1: to --no-html. --api might be considered too generic, and it's not clear what things will be excluded.

[josevalim]

@evax I am :-1: on adding more options unless necessary. The only reason for adding --no-html (or --api) is because the HTML changes are quite pervasive and touch many files. When it comes to channels, it is mostly a matter of deleting the channel folder.

[railsmechanic]

IMHO one of the "main problems" with rails and even the rails-api gem is/was that you have to disable and remove a lot of components manually to get an API foundation of an "acceptable level". As Phoenix is quite new, you're able to integrate this function right from the beginning. So I think a command line switch that bypasses generation of all unused components would lead to a good API foundation without the need of using third party packages.

[evax]

@josevalim I get your point. Arguably we could define a phoenix.new.api task with its own set of options to keep phoenix.new clean. That would have the added benefit of making things more modular and ease the task of writing derived phoenix app generators.

[josevalim]

@railsmechanic the main problem with Rails is that you need to go through a bunch of hops to disable behaviour in the first place since all of your middleware stack, dependencies and what not are hidden from you.

This is much less of a problem with Phoenix because the phoenix_html dependency is explicit, the imports are explicit, and the pipelines are explicit. So all we need to do is to _not generate code_, in contrast to _generate new code that disables the defaults_.

In other words, Rails gives you x + y + z and the only way to remove HTML is by removing y and z in your app by adding lines of code to remove that functionality. Phoenix gives you x and y + z exists only in your app, so it is straight-forward to remove them.

That's also why I think we don't need phoenix.new.api and why I prefer --no-html. It is not a matter of generating something special, it is a matter of simply _not generating_ something.

[railsmechanic]

@josevalim I know, but now you're able to do it right :smile:

[lexmag]

It is not a matter of generating something special, it is a matter of simply not generating something.

Well said. :smile:
--no-html feels self-explanatory. But --api needs description that this is about excluding html, and not about generating JSON templates, for example.

[stevedomin]

I prefer --no-html as well, that's what I used so far. PR to land soon

[vol0da]

:+1: to --no-html

as @lexmag said, it's self-explanatory

[scrogson]

--no-html is also consistent with --no-ecto, --no-brunch, etc.
On Wed, Sep 9, 2015 at 04:57 Vladimir Galajda [email protected]
wrote:

[image: :+1:] to --no-html

as @lexmag https://github.com/lexmag said, it's self-explanatory

—
Reply to this email directly or view it on GitHub
https://github.com/phoenixframework/phoenix/issues/1192#issuecomment-138860750
.

[optikfluffel]

:+1: for --no-html

[chrismccord]

That's also why I think we don't need phoenix.new.api and why I prefer --no-html. It is not a matter of generating something special, it is a matter of simply not generating something.

@josevalim great points. Let's do --no-html

[jonhkr]

:+1: for --no-html

[esdrasedu]

:+1: for --no-html

[amarsahinovic]

Instead of all these separate flags like --no-brunch, --no-html and in a year from now maybe a dozen new, I would recommend that a single --template flag replaces them. You would provide it the path to a directory which holds skeleton Phoenix project template, like the one used in phoenix.new but customized to include/exclude just what you need, like html support removed or it could include stuff like auth and user management.

This is a feature that I use in my Django projects to bootstrap them faster by preconfiguring them to suit my usual needs. Docs: https://docs.djangoproject.com/en/1.6/ref/django-admin/#django-admin-option---template

You could even extract the installer directory from phoenix repo so people can fork it easier and maintain their project templates.

Sorry for any mistakes, I'm typing this from my mobile.

[jonhkr]

In addition to @amarsahinovic, Pyramid also has a scaffold system based on templates. This system allows the community to create custom scaffolding templates based on their needs.
Docs: http://docs.pylonsproject.org/projects/pyramid//en/latest/narr/project.html

[optikfluffel]

Hoodie has something like this too, I guess something similar using hex would be pretty cool:

Now of course, you won't want to start coding with the Hoodie demo application every single time, which is why hoodie new supports templates.

Templates can either come in the form of npm packages
hoodie new appname -t npm package
or github repositories
hoodie new appname -t githubusername/reponame

Here's a boilerplate template you can start your next Hoodie app with.

[wsmoak]

Not to derail this specific addition, but +1 for different templates rather continuing to add switches.

Recovering Java developers will remember mvn archetype:create ... which allowed anyone to create a skeleton suited to their particular project type, with the right dependencies pre-filled, etc., and share it via the central repo.

Does this possibly belong in Mix instead of Phoenix though? mix new my_project --template phoenix.json_api ?

[chrismccord]

Does this possibly belong in Mix instead of Phoenix though? mix new my_project --template phoenix.json_api ?

There is a discussion on an elixir-lang issue somewhere around mix templates, but nothing has materialized yet. That is something which shouldn't be a concern for phoenix imo.

Instead of all these separate flags like --no-brunch, --no-html and in a year from now maybe a dozen new, I would recommend that a single --template flag replaces them. You would provide it the path to a directory which holds skeleton Phoenix project template, like the one used in phoenix.new but customized to include/exclude just what you need, like html support removed or it could include stuff like auth and user management.

--no-html is pretty much the end of the road for no-... options, so no worries about a dozen options a year from now. I'm not convinced a skeleton generator is necessary today for generating applications. Thanks for the feedback!