I have VueJS GUIs with the project generated using Webpack.
I have Elixir modules that will need to be used by the VueJS GUIs.
I foresee I will eventually have an umbrella Phoenix project. Right now it is just VuejS, Javascript, and Elixir modules.
I need to merge the files from VueJS, Elixir, & Phoenix into 1 project.
I need it to eventually be a compiled standalone app.
I have no clue where to go next doing this according to conventions.
Anyone have a guide or tutorial for the next steps?
I read through this litterally 5 minutes ago.
I will be starting this tomorrow morning myself.
FYI:
Though it also involves nanobox, so it’s likely of limited use …
There are some github projects which use phoenix + vue
[-] https://github.com/akeating/pespa
[-] https://github.com/ssuprunenko/phoenix-vue-2-example
[-] https://github.com/jespr/vue-phoenix-chat
[-] https://github.com/loongmxbt/pxvue
The best example I know:
It’s a pretty good example, its a SPA example but think can help a lot
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:
--no-brunch option. It’s simply easier to delete the brunch-config.js and modify the package.json to strip out “project-level brunch”, but all this has to happen before the dependencies are loaded so,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.
https://github.com/odiumediae/webpacker <- Although its for react it shows how to integrate phoenix 1.3 with webpack 2.
You could just toss brunch and use npm as a build system, after all it is, and you already have it. 
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”).
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.
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.
[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?
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
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.
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
Do you know of any example projects available on github using VueJS and Phoenix 1.3? Thank you.
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.
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.
© Copyright Elixir Forum | Terms | Privacy & Cookies
