How To Get Phoenix & VueJS working Together?

I read through this litterally 5 minutes ago.
https://gist.github.com/jlauemoeller/d53ddd028387cd139c31bf2282dd12f4

I will be starting this tomorrow morning myself.

FYI:
https://content.nanobox.io/phoenix-vue-js-running-in-minutes/

Though it also involves nanobox, so it’s likely of limited use …

There are some github projects which use phoenix + vue

[-] GitHub - akeating/pespa: A demonstration of single page applications (Vuejs / Elm) with api server (Elixir/Phoenixframework) using graphql subscriptions. · GitHub
[-] GitHub - ssuprunenko/phoenix-vue-2-example: Elixir Phoenix, Brunch, Vue.js 2.0 · GitHub
[-] GitHub - jespr/vue-phoenix-chat: Chat built with Vue.js 2.0 and the Phoenix Framework (Elixir) · GitHub
[-] GitHub - loongmxbt/pxvue: Phoenix + Vue + Webpack · GitHub

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:

• It is recommended to ignore the --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,
• 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.

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.