hurricanenate
My company is taking its first steps in integrating an existing React SPA into a brand-new Phoenix app. We’ve set up auth using phoenix.gen.auth, and are looking at the first case where we need Phoenix-generated data in our UI layer: adding a logout link to our header.
This is how the link is generated in _user_menu.html.heex:
<li><%= link "Log out", to: Routes.user_session_path(@conn, :delete), method: :delete %></li>
What’s the best way to recreate this in our React app?
The first approach I came up with was to add a template that puts any data we might need into a <script></script> tag and attaches it to the window object so that our React components could grab it. This is how I implemented it:
root.html.heex:
<head>
...
<%= render "_script_data.html", assigns %>
...
</head>
_script_data.html.heex:
<script type="text/javascript">
window.dashboardAppData = {
currentUser: {
<%= if @current_user do %>
email: '<%= @current_user.email %>',
<% end %>
},
csrfToken: document.querySelector("meta[name='csrf-token']").getAttribute("content"),
routes: {
userSessionDelete: '<%= Routes.user_session_path(@conn, :delete) %>',
...
}
}
</script>
My React component, HeaderToolbar.js:
function HeaderToolbar() {
const appData = window?.dashboardAppData;
return (
{appData && (
<a
href={appData.routes.userSessionDelete}
data-to={appData.routes.userSessionDelete}
data-method="delete"
data-csrf={appData.csrfToken}
>
Log Out
</a>
}
)
}
This approach seems workable, but far from ideal: I don’t love the step of creating a giant object of data and making decisions each time about naming conventions. I also lose the utility of the <%= link ... %> tag, as I’m forced to recreate what a Phoenix link looks like, mirroring the necessary data attributes first by rendering it normally in a template and then recreating it in my React component.
Does anyone have any suggestions for better ways to approach this integration? Whatever choices we make at this point will determine the pattern for how we do quite a bit of other work and I’d like to find the best option possible.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tomkonidas
There is a chapter at the end of Real-Time Phoenix that goes into integrating with other front ends using channels.
There is specifically a section Exploring Front-End Technologies → Single-Page Apps with React
hurricanenate
Thanks a lot for that tip—I’ve just purchased the book and will check it out ASAP.
hurricanenate
One question: it looks like the book deals with integrating with Phoenix channels, which I understand to be open connections that let you receive data as it is updated or changed directly from the server. Does it deal at all with the question of how to integrate the rendering layer, as in my example with the log out button in the OP? Right now I’m most curious about how to approach the rendering layer of views in React components.
kokolegorille
There is a tool to help rendering React with Elixir.
I am curious about the previous backend, and how it was working before.
tomkonidas
I would think so. Looking fast at the book on page 280.
I assume the presentation components are the ones you are interested in. It looks like he is using normal React Router. You would probably still need to do some sort of JSON API/GraphQL/Channels call in the route component I would guess. This also would depend if you are only using React, or just sprinkling it in a Phoenix app. The way he shows in the book I believe would be using React as the only front end and then using Channels to talk to the Phoenix backend.
joaoevangelista
hi!
idk if I understood correctly, but you want to pass to the react components the result of
Routes.user_session_path(@conn, :delete)so it can know what url to call to log out?Is the react app being embedded in a phoenix template? If so, you could assign the routes to an object at the
window, as you did, or maybe as a prop to your main react component ?hurricanenate
Yeah, that approach definitely works. I was hoping for a more integrated solution that doesn’t require those kinds of explicit pass-throughs.
hurricanenate
This approach may make the most sense: my colleague was recommending we try an SSR-like approach using Phoenix’s
render_to_stringmethod, and it looks like ReactRender basically is a more fully realized version of that approach: I’ll be giving that a try today.The SPA also interacts with a separate go app via rest endpoints, and will continue to do so. We’re adding the Phoenix app as a way of giving this app the ability to handle its own separate, user-related concerns, which is why adding authentication is our first step.
kokolegorille
This is how I would do with a Phoenix Backend, either REST or GraphQL, with Absinthe.
But I don’t see how You want to procede… using phx.gen.auth is not done for API.
And SPA have their own router, their own authentication, usually with a Phoenix Token.
Unless You want to use Phoenix, with React as the View layer.
You can pass data from backend to frontend via data attributes, even json encoded attributes, that You could parse JS side.
You can use Hooks if You use liveview, as a way to interact with JS.
bpaulino0
Probably very late on the topic, but back in 2022, I wrote a blogpost on how to integrate the entire React pipeline within Phoenix so you can have a decent developer experience, but also a reasonable deployment pipeline that does not compromise on your current Elixir/Phoenix build steps.
I think the most challenging part is to make sure that you have a up2date build step for your SPA app and at the same time you don’t change your Phoenix setup too much. And you only need NodeJS during build-time.