How are Phoenix javascript assets callable from the browser console?

Let’s say I have some methods in my PATH/assets/js/app.js that manipulate channels, and am in the process of developing them.

How can I go to the browser console that is accessing my phoenix development server and call those methods?

For instance, in other frameworks, or even bare javascript, I’ve been able to call something like App.METHOD or window.someapp.METHOD in order to access the loaded methods. But, poking around in the browser console, I haven’t been able to find any obvious (to me) routes to access the app functions.

1 Like

By default Brunch deposits all the bundled javascript into app_name/priv/static/js/app.js (and also supplies a source map app_name/priv/static/js/app.js.map).

While the source map makes debugging easier, arbitrarily invoking functions from the browser console will probably require some poking around in the raw app.js bundle to locate the equivalent code in the bundle.

So those are directories in the phoenix project (app_name/priv).

But, what is the root in browser console? There doesn’t appear to be an app_name* or window.app_name or window.map.app_name or other namespaced function in the browser that allows calling the javascript assets.

Or are you saying that I’d have to poke around in the 17k lines of code in the app.js file to find the appropriate namespace (as there may not be a default)?

Well, part of Brunch’s job is

… to prohibit global public access and encapsulate code.

So you can simply breach that encapsulation by assigning something on the window yourself in app.js

window.myAccess = toSomething;

or if the functionality resides in a module you can in the brunch-config.js:

  npm: {
    enabled: true,
    globals: {myModule: 'js/my-module'}
  }

Then the exports of my-module will be found within the object on window.myModule. This works for your own modules, not just those residing under node_modules.

2 Likes

Thank you so much for clarifying.

Then it looks like doing such things for debugging/developing the client-side api is typically done with purely the dev environment and live reloading only?’

Not exactly. Inspecting things via the global scope is more of a jQuery-era (pre-module) type of tactic.

Brunch does generate a source map app.js.map that allows a debugger like the one that is part of Chrome’s Developer Tools to step through the original JavaScript source rather than the transpiled/bundled code. So you are always able to set a breakpoint based in the original code and then inspect and manipulate all the variables that are in scope at that point of execution through the browser console.

That of course doesn’t help when you only have access to the global scope which is typically the case when you aren’t currently paused on a breakpoint. So libraries/frameworks like React or Vue.js tend to offer browser plugins that give you detailed access to the library internals and potentially even create some development-only global references to make matters a bit more convenient.

1 Like