The best example I know:
It’s a pretty good example, its a SPA example but think can help a lot
4 Likes
Well, it kind of works, there were a few minor omissions here and there - nothing that couldn’t be sussed out fairly quickly. But there was something that bothered me:
don’t forget to add a proper include statement to your application layout
web/templates/layout/app.html.eex:
<link rel="stylesheet" href="<%= static_path(@conn, "/css/components.css") %>">`
Say what? Brunch is a bundler and the default Phoenix project bundles to priv/static/css/app.css (/css/app.css to the outside world). Why do I need another CSS file? It turns out that Brunch’s plugin ordering seems to be determined to the some degree by the order they are found in the package.json dependencies (which is automatically kept in alphabetical order). So css-brunch runs before javascript-brunch followed by vue-brunch, So that CSS file generated by vue-brunch comes into existence too late to be bundled with the other CSS files - so the workaround is to have the Vue CSS in a separate file. Now there is a discussion around possibly being able to order Brunch plugins in the future - but I’m starting to wonder if Brunch is showing its age (i.e. being geared towards a different kind of web development workflow).
Furthermore I can’t help but get the impression that Vue tooling tends to favour Webpack. So it may be worth considering getting on the Webpack bus sooner than later. Now Using Webpack with Phoenix and Elixir only deals with webpack 1.13 - but it still gives a good guide to the “integration points” that need to be taken care of. There are two possible surprises:
- It is recommended to ignore the
--no-brunchoption. It’s simply easier to delete thebrunch-config.jsand modify thepackage.jsonto strip out “project-level brunch”, but all this has to happen before the dependencies are loaded so, - decline the automatic installation of the dependencies when the project is generated.
There is also a Brunch dependency in config/dev.exs that needs to be adapted. Once the configuration files have been adapted it’s easy enough just to load them later with mix deps.get - at this point in time Brunch is still used on the dependency level to generate phoenix_html.js and phoenix.js. Interestingly live-reloading doesn’t actually rely on Brunch (article: Behind the magic of Phoenix LiveReload).
So it might make sense to become familiar with Webpack 2 on a Phoenix base install and once all of that seems to work, push further by adding Vue into the mix.
2 Likes
https://github.com/odiumediae/webpacker <- Although its for react it shows how to integrate phoenix 1.3 with webpack 2.
1 Like
You could just toss brunch and use npm as a build system, after all it is, and you already have it. 
1 Like
I know - I was kind of heading there:
// package.json
{
"repository": {},
"license": "MIT",
"scripts": {
"watch": "npm-run-all --parallel watch:*",
"build:assets": "rsync -r ./web/static/assets/ ./priv/static",
"build:css": "cat ./web/static/css/phoenix.css ./web/static/css/app.css > ./priv/static/css/app.css",
"watch:css": "watch 'npm run build:css' ./web/static/css/",
"build:js": "rollup -c",
"watch:js": "rollup -c -w",
"build": "npm run build:js && npm run build:css"
},
"dependencies": {
"phoenix": "file:deps/phoenix",
"phoenix_html": "file:deps/phoenix_html"
},
"devDependencies": {
"babel-plugin-external-helpers": "^6.22.0",
"babel-preset-latest": "^6.24.1",
"npm-run-all": "^4.0.2",
"rollup": "^0.41.6",
"rollup-plugin-babel": "^2.7.1",
"rollup-plugin-commonjs": "^8.0.2",
"rollup-plugin-node-resolve": "^3.0.0",
"rollup-watch": "^3.2.2",
"watch": "^1.0.2"
}
}
.
// rollup.config.js
import resolve from "rollup-plugin-node-resolve";
import commonjs from "rollup-plugin-commonjs";
import babel from 'rollup-plugin-babel';
export default {
entry: "web/static/js/app.js",
format: "iife",
plugins: [
resolve({
browser: true,
preferBuiltins: false,
customResolveOptions: {
moduleDirectory: [
"deps/phoenix/priv/static",
"deps/phoenix_html/priv/static"
]
}
}),
commonjs({
ignoreGlobal: true
}),
babel({
exclude: [
'node_modules/**',
'deps/**'
]
// for everything else use .babelrc
})
],
dest: "priv/static/js/app.js"
}
.
# config/dev.exs
...
code_reloader: true,
check_origin: false,
watchers: [node: ["node_modules/npm-run-all/bin/npm-run-all", "--parallel", "watch:*",
cd: Path.expand("../", __DIR__)]]
...
But there don’t seem to the caliber of “one-thing-only” tools that cover the other build aspects the way rollup.js has got the JavaScript build covered. PostCSS is promising but for example this gets gulp involved to do bundling - not going down that rabbit hole.
Also I think it may be too great a cost to give up on the integration support that Vue seems to have with webpack (even though there seem to be enough people who cringe when they hear “webpack”).
1 Like
Hi Emily, I lean towards keeping it simple. My suggestion would be to keep your vuejs client directory out of the phoenix build system. You gain the integrated development and build environment that’s so well supported by vuejs. Create apis in phoenix that your vuejs application can call and update your view using vue. When you’re ready to deploy to production, generate the production build and serve it statically with a proxy of your api calls to your elixir/phoenix api endpoints. The vue production build is in the dist directory but you can configure it to place it anywhere, even directly into your phoenix directory structure if you prefer.
4 Likes
Its this line right? https://github.com/phoenixframework/phoenix/blob/master/installer/templates/new/config/dev.exs#L27
Do you know if there is a reason this is not something like
watchers: <%= if brunch do %>[npm: ["run", "watch", cd: Path.expand("../", __DIR__)]]<% else %>[]<% end %>
since there is already a watch script on package.json.
This would make even easier to switch front end tooling.
1 Like
[quote=“idiot, post:4, topic:5108”]
Hi Emily, I lean towards keeping it simple. My suggestion would be to keep your vuejs client directory out of the phoenix build system. You gain the integrated development and build environment that’s so well supported by vuejs. Create apis in phoenix that your vuejs application can call and update your view using vue. When you’re ready to deploy to production, generate the production build and serve it statically with a proxy of your api calls to your elixir/phoenix api endpoints. The vue production build is in the dist directory but you can configure it to place it anywhere, even directly into your phoenix directory structure if you prefer.[/quote]
Some newbie questions regarding this solution:
If I use 2 separate build tools, Brunch for Phoenix, and Webpack for VueJS, while developing I’m running VueJS on localhost:8080/ & VueJS on http://localhost:4000 simultaneously?
Router:
I imagine I would use the VueJS router on the front ends & not the Phoenix router?
For file structure:
I simply separate VueJS build into a top level client folder, and Phoenix into a top level server folder?
I imagine that Websockets will work passing variables between Phoenix on localhost:8080/ & VueJS on http://localhost:4000 synchronously, so long as they are both running?
2 Likes
Hi Emily, I’m in the same boat as you right now. I created two seperate projects, one for the client (Vue) and one for the API (Phoenix), just like what @adamk mentioned and using vue-router for client app routing and works great
1 Like
You can run them together as long as you can run them separately (i.e. something like a personal firewall or account permissions isn’t blocking access to the ports). They just couldn’t be using the same port.
You are still going to use the Phoenix router because that is the server side router and WebSockets are addressed with URIs. So for example you would put something like this in web/router.ex
socket "/ws", Backend do
channel "rooms:lobby", RoomChannel
end
(Content borrowed from here)
Note that you can leave out brunch and eex template support with
mix phoenix.new project_name --no-brunch --no-html
You can still find the client-side phoenix.js library needed for Phoenix channel access under deps/phoenix/priv/phoenix/static
Phoenix mix tasks are itemized here and most of them are explained here.
To access the phoenix channels from the browser you’ll use something like this:
import {Socket} from "phoenix"
...
let socket = new Socket("ws://localhost:4000/ws");
socket.connect();
let chan = socket.chan("rooms:lobby", {});
chan.join().receive("ok", () => {
console.log("Welcome to Phoenix Chat!");
});
(I imagine the import statement may need to be adjusted to comply with the webpack build process).
They are two separate projects … so personally I would keep them entirely separate especially as there is a second server serving the Vue.js pages (so if you are suggesting sibling client (Vue.js dev) and server (Phoenix dev) folders for development that’s ok). I wouldn’t join them if and when you are ready to tackle Phoenix serving the Vue.js pages (and building them together) - and by that point in time Phoenix 1.3 final (with a sightly different folder structure) may be available.
1 Like
During development you proxy api calls via webpack-dev-server, so you can safely use relative urls from your Vuejs code. In production, you would also proxy the api calls, bt using a different tool, such as nginx or caddy.
You could use both routers. It’s not all-or-nothing here. Say your vue application is served from /app then the vue router would be responsible for everything it can control, ie relative to /app. The answer depends on what you’re trying to build. If you intend using vue for the entire website, say for a admin panel, then just have vue handle everything and setup phoenix appropriately.
Your code would be organized like this:
--src
-- client
-- server
webpack-dev-server can also proxy websockets, so you could use relative urls everywhere.
There’s a demo of this architecture (minus the websockets piece) at https://github.com/akeating/pespa
1 Like
Do you know of any example projects available on github using VueJS and Phoenix 1.3? Thank you.
1 Like
PragDave has a section on Vue.JS in his online course:
It’s not a comprehensive section but just shows how websockets can be used with something like Vue.
1 Like
Hey look at these two posts, one is not related to VueJs but to separating your javascript so to have certain views render only certain JS, this will be useful when you have several vuejs components and you only want some to be loaded in some views, and others in other views.
https://blog.diacode.com/page-specific-javascript-in-phoenix-framework-pt-1
This other goes on on how to build a chat web app with VueJS and phoenix (has a repo too) - although it’s about a web chat app, since it uses channels you can basically leverage what’s there to build anything that coms with the back-end.
1 Like
Seems to me lots of blogs about Phoenix get into Brunch like it’s somehow an essential part of Phoenix - it isn’t. When it comes to the development workflow there is one loose “connection” to Brunch in my_app/config/dev.exs - the watchers configuration. It contains the command to start up the process responsible for building bundles whenever the primary files change. Phoenix LiveReload is then responsible for supplying the re-built files to the browser via a hidden <iframe> which coordinates the necessary updates in the browser.
Vue with Webpack (instead of Brunch) can make use of the same mechanism. To demonstrate, start with a simple Vue.js component project:
$ tree assets
assets
├── build
│ └── webpack.dev.conf.js
├── images
├── index.html
├── js
├── package.json
└── src
├── App.vue
├── assets
│ └── phoenix.png
└── main.js
assets/index.html:
<!DOCTYPE html>
<html>
<head>
<!-- assets/index.html -->
<meta charset="utf-8">
<title>Vue.js Demo Page</title>
</head>
<body>
<div id="app"></div>
<script src="js/app.js"></script>
</body>
</html>
assets/src/App.vue:
<template>
<div class="foo">
<img src="./assets/phoenix.png">
<h1>{{ msg }}</h1>
<button id="change-message" @click="changeMessage">Change message</button>
<p>{{ passedProp }}</p>
</div>
</template>
<script>
export default {
name: 'hello',
data() {
return {
msg: 'Welcome to Your Vue.js App'
};
},
props: ['passedProp'],
methods: {
changeMessage() {
this.msg = 'new message';
}
}
};
</script>
<style>
.foo {
font-family: 'Avenir', Helvetica, Arial, sans-serif;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
text-align: center;
color: #2c3e50;
margin-top: 60px;
}
</style>
assets\src\main.js:
// src/main.js
import Vue from 'vue';
import App from './App';
Vue.config.productionTip = false;
new Vue({
el: '#app',
template: '<App passedProp="Greetings!" />',
components: { App }
});
assets/build/webpack.dev.conf.js:
// build/web.config.dev.js
const path = require('path');
const webpack = require('webpack');
const FriendlyErrorsPlugin = require('friendly-errors-webpack-plugin');
const PATHS = {
assetsRoot: '/',
assetsSubDirectory: '/'
};
function assetsPath(filePath) {
return path.posix.join(PATHS.assetsSubDirectory, filePath);
}
function resolve (dir) {
return path.join(__dirname, '..', dir);
}
module.exports = {
entry: {
app: './src/main.js'
},
output: {
filename: 'js/[name].js',
path: resolve(PATHS.assetsRoot)
},
resolve: {
extensions: ['.js', '.vue', '.json'],
alias: {
'vue$': 'vue/dist/vue.esm.js',
'@': resolve('src')
}
},
module: {
rules :[
{
test: /\.vue$/,
loader: 'vue-loader'
},
{
test: /\.js$/,
loader: 'babel-loader',
query: {
presets: ['env']
},
include:[resolve('src')]
},
{
test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
loader: 'url-loader',
options: {
limit: 20000,
name: assetsPath('images/[name].[hash:7].[ext]')
}
}
]
},
// cheap-module-eval-source-map is faster for development
devtool: '#cheap-module-eval-source-map',
plugins: [
new webpack.NoEmitOnErrorsPlugin(),
new FriendlyErrorsPlugin()
],
watchOptions: {
ignored: /node_modules/
}
};
assets/package.json:
{
"name": "assets",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"devbuild": "node ./node_modules/webpack/bin/webpack.js --config ./build/webpack.dev.conf.js",
"watch": "./node_modules/.bin/webpack --watch-stdin --config ./build/webpack.dev.conf.js"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"babel-core": "^6.26.0",
"babel-loader": "^7.1.2",
"babel-preset-env": "^1.6.0",
"css-loader": "^0.28.7",
"file-loader": "^1.1.5",
"friendly-errors-webpack-plugin": "^1.6.1",
"url-loader": "^0.6.2",
"vue-loader": "^13.0.5",
"vue-style-loader": "^3.0.3",
"vue-template-compiler": "^2.4.4",
"webpack": "^3.6.0"
},
"dependencies": {
"vue": "^2.4.4"
}
}
Check this project with:
assets $ npm i
...
added 623 packages in 10.714s
assets $ npm run watch
> assets@1.0.0 watch /Users/wheatley/sbox/vue/phx/assets
> webpack --watch-stdin --config ./build/webpack.dev.conf.js
Webpack is watching the files…
...
^C assets $
At this point it should be possible to view assets/index.html through a browser from the filesystem.
Now create a new Phoenix 1.3 project:
assets $ cd ..
$ mix phx.new my_app --no-brunch --no-ecto
and create a new directory my_app/assets and copy the following files into it:
my_app/assets
├── build
│ └── webpack.dev.conf.js
├── package.json
└── src
├── App.vue
├── assets
│ └── phoenix.png
└── main.js
Modify my_app/assets/build/webpack.dev.conf.js
// build/web.config.dev.js
const path = require('path');
const webpack = require('webpack');
const FriendlyErrorsPlugin = require('friendly-errors-webpack-plugin');
const PATHS = {
assetsRoot: '../priv/static', // CHANGED
assetsSubDirectory: '/'
};
function assetsPath(filePath) {
return path.posix.join(PATHS.assetsSubDirectory, filePath);
}
function resolve (dir) {
return path.join(__dirname, '..', dir);
}
module.exports = {
entry: {
app: './src/main.js'
},
output: {
filename: 'js/[name].js',
path: resolve(PATHS.assetsRoot)
},
resolve: {
extensions: ['.js', '.vue', '.json'],
alias: {
'phoenix': resolve('../deps/phoenix/priv/static/phoenix.js'), // ADDED
'phoenix_html': resolve('../deps/phoenix_html/priv/static/phoenix_html.js'), // ADDED
'vue$': 'vue/dist/vue.esm.js',
'@': resolve('src')
}
},
module: {
rules :[
{
test: /\.vue$/,
loader: 'vue-loader'
},
{
test: /\.js$/,
loader: 'babel-loader',
query: {
presets: ['env']
},
include:[resolve('src')]
},
{
test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
loader: 'url-loader',
options: {
limit: 20000,
name: assetsPath('images/[name].[hash:7].[ext]')
}
}
]
},
// cheap-module-eval-source-map is faster for development
devtool: '#cheap-module-eval-source-map',
plugins: [
new webpack.NoEmitOnErrorsPlugin(),
new FriendlyErrorsPlugin()
],
watchOptions: {
ignored: /node_modules/
}
};
Note the modified PATHS.assetsRoot and the additions to resolve.alias.
Modify my_app/assets/src/main.js:
// src/main.js
import Vue from 'vue';
import App from './App';
import 'phoenix_html'; // ADDED
// import socket from "./socket";
Vue.config.productionTip = false;
new Vue({
el: '#app',
template: '<App passedProp="Greetings!" />',
components: { App }
});
Install the supporting packages:
assets $ npm i
...
added 623 packages in 11.886s
Give it a quick check:
$ npm run watch
> assets@1.0.0 watch /Users/wheatley/sbox/vue/phx/my_app/assets
> webpack --watch-stdin --config ./build/webpack.dev.conf.js
Webpack is watching the files…
...
^C assets $
Now modify watchers in my_app/config/dev.exs:
config :my_app, MyAppWeb.Endpoint,
http: [port: 4000],
debug_errors: true,
code_reloader: true,
check_origin: false,
watchers: [node: ["node_modules/webpack/bin/webpack.js", # CHANGED
"--watch-stdin",
"--config", "./build/webpack.dev.conf.js",
cd: Path.expand("../assets", __DIR__)]
]
to kick off Webpack watching the frontend source files.
The same thing can be accomplished by specifying a suitable npm run script, however this rather verbose incantantion is necessary for some MS Windows installations.
Replace my_app/lib/my_app_web/templates/layout/app.html.eex with
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="">
<meta name="author" content="">
<title>Hello MyApp!</title>
</head>
<body>
<%= render @view_module, @view_template, assigns %>
<script src="<%= static_path(@conn, "/js/app.js") %>"></script>
</body>
</html>
and my_app/lib/my_app_web/templates/page/index.html.eex with
<div id="app"></div>
Finally start Phoenix
assets $ cd ..
my_app $ mix phx.server
Compiling 12 files (.ex)
Generated my_app app
[info] Running MyAppWeb.Endpoint with Cowboy using http://0.0.0.0:4000
Webpack is watching the files…
DONE Compiled successfully in 924ms20:40:49
...
[14] ../deps/phoenix_html/priv/static/phoenix_html.js 1.23 kB {0} [built]
+ 6 hidden modules
Now open the browser at http://localhost:4000/ to see the “Hello MyApp!” page.
If you modify the message text in my_app/assets/src/App.vue Phoenix LiveReloader will update the page in the browser shortly after you save the file (and the bundle has been rebuilt).
With a basic setup like this it should be possible to go further by “scavenging” features from other non-Phoenix Vue “donor” projects like the ones generated by vue-cli, e.g. $ vue init webpack my-project.
8 Likes
Brunch and webpack both are horrid and I don’t use them in my work project, I just use raw npm scripts (which is really what phoenix should do by default as it shows how you could plug in anything then). ^.^
3 Likes
I think adopters simply need to be reminded that there is no Brunch “lock-in” with Phoenix - i.e. there is the freedom to use the frontend technologies that are the most appropriate for the job.
Brunch seems to be most appropriate for projects that primarily rely on server side EEx templates with some JavaScript widgets thrown in, using modules for code organization. Brunch is beginner-friendly for learning Phoenix with reference to the guides and the book - but IMO isn’t the right entry into the “modern JavaScript toolchain” - ultimately you have to start with npm/node. But JavaScript tooling is only a tangential concern to Phoenix’s role and existence and people need to stop assuming that every “out-of-the-box default” is automatically the best solution for their particular situation (while “Batteries included” products tend to be more popular, they can lead to “square peg in a round hole” solutions if defaults aren’t properly adapted).
Now Vue.js tooling strikes me as having a strong affinity/bias towards Webpack as a module bundler/build tool, so trying to use any other means (including Brunch) could possibly risk grief in the future. That being said Webpack is primarily optimized for “client-side generated DOM” based solutions, so the utility of server side EEx templates is somewhat limited; beyond --no-brunch --no-html may also be appropriate (possibly serving the frontend separately). However there could be use cases for Vue.js (with Webpack) + EEx templates as Vue.js promotes itself as “incrementally adoptable”.
1 Like
