How do I log something to inspect? (And getting a (Phoenix.Router.NoRouteError) error)

Playing around with hologram for the first time and I have 2 initial questions / concerns:

(1) How do I log something to inspect? Do I need the ceremony of creating an action to do so?

Edit: it looks like IO.inspect works directly. I’m not exactly sure why my session data is empty, though.

(2) Pages are working but my logs are constantly emitting the following warning. How to address?

(Phoenix.Router.NoRouteError) no route found for GET /deps/hologram/assets/node_modules/snabbdom/src/vnode.ts

and sometimes:

(Phoenix.Router.NoRouteError) no route found for GET /hologram/runtime-d374f1e10420e534ae083f70d04d55da.js

Thank you in advance!

3 Likes

You just do IO.inspect("something") and check the output in the browser console.

You can safely ignore this. More details here:
https://github.com/bartblast/hologram/issues/275
The problem will be resolved once Snabbdom is vendored (which is planned to eliminate the Node/npm dependencies).

1 Like

Thanks @bartblast. Is my session supposed to be prepopulated? I saw that Server.from(conn) appears to extract it, but I’m not having success finding my authenticated ”user”. Only some CSRF tokens in there.

1 Like

Correct, you should be able to see the Phoenix session data in the Hologram.Server struct.

@dillonoconnor Can you try to reproduce the session problems using the Hologram Skeleton app?

I have sort of figured things out. My app is mixed phx liveview and hologram and the session cookie gets stored in an encrypted state, which is what the hologram page is able to access.

Since there is not easy access to Plug.Session decryption (or conn) in this context things get a little complicated. I can think of a couple okay workarounds. Not sure if there is a known good pattern to handle this? I’m thinking I can either add limited unencrypted data to the session (not secure…) on login OR pull in some decryption flows :person_shrugging: Another issue is determining whether or not the user is logged in to begin with.

FWIW I figured out a solution using AshAuthentication.Jwt.verify/4 with the session’s user_token.

I’m not sure why ”user_token” is present but ”user” from session (which is visible inspected from a LiveView) is missing.

Hologram has full access to all data needed to correctly read and write to the Phoenix session via Plug.Conn.get_session() and Plug.Conn.put_session(). The framework is designed for seamless interoperability with Phoenix - session data should work identically whether you’re using LiveView or Hologram. If certain session values that are visible in LiveView are missing in Hologram, that’s probably a bug and needs to be investigated.

The fact that you’re seeing user_token but not user suggests something specific about how your authentication system stores data in the session. It’s possible that the user value is being stored differently (or conditionally) between LiveView and regular requests.

Can you create a basic repo that reproduces the problem? This will help me track down the issue and apply the fix. A minimal example that shows:

  1. A LiveView route where you can see the full session data (including user)
  2. A Hologram page route where the same session data should be visible but isn’t

This will make it much easier to debug what’s happening with the session handling. Getting this fixed will also benefit other users who might run into similar issues when mixing LiveView with Hologram pages in the same application.

I figured it out (again :laughing:). I’m using ash_authentication which apparently works by injecting ephemeral data into the session value within an ash_authentication_live_session, i.e. it doesn’t actually store the values in the cookie–see the source code for generate_session. I inspected the session on a route outside of the live session and only saw the user_token as we observed on the Hologram page. Apologies, I am new-ish to Ash and am still learning a lot about the ecosystem.

As Hologram pages define their own routes, I’m not so sure if it’s possible to take advantage of the generated session data from Ash. More to look into :thinking:

1 Like