How can a front-end developer collaborate with a back-end developer on a Phoenix 1.7 and LiveView project?

Hello everyone!

As a back-end developer who dislikes front-end work such as CSS and is not proficient in web and graphic design, I have the opportunity to collaborate with someone who is really experienced and skilled in these areas. Unfortunately, as I dislike CSS, he dislikes back-end development. So it’s not worth asking him to learn Phoenix or LiveView; I already know his answer. However, we have to work together on a Phoenix 1.7 and LiveView project.

I’m wondering how we can collaborate effectively to ensure that the project runs smoothly.
Specifically, I’m interested in learning how a front-end developer can design an HTML template styled with Tailwind CSS that can be easily used with Phoenix/LiveView.

Can anyone help me with some resources, tools or tips on how to get started? Or if you want to share your own experience on such collaboration, it would be welcome too! Thank you!”

Side note: “I’m still in the learning process with LiveView and its Components based Design approach. The front-end developer also is new to Tailwind CSS but somehow I managed to convince him to learn it so we can keep the LiveView defaults… I probably will learn also some Tailwind basics. So if my question is a bit naive, please bear with me.

1 Like

Hello! I am happy to give my experience as we are in a similar situation.

On our current project my wife is one of the backend dev and the lead LiveView dev. My job is to do the UI and styling, along with many other things. My primary skills are in design, HTML, CSS, and some JS and an understanding of building website (plus GDPR, hosting, email services, etc.)

So my wife and I work together. She does the business logic and backend and then turns it over to me to make it look good, test it etc.

I do know a good amount of Elixir and Phoenix. I was hesitant about Tailwind but like it now. To use Tailwind you should be using components (like you would in React etc.). If you don’t, then it will be hard to maintain the CSS. Also, using Phoenix plus Tailwind is very nice. You can use attributes, slots, Phoenix.LiveView.JS, etc to do some amazing things on the front-end…really nice to work with.

Your front-end dev could give you the basic HTML templates but you would then need to add them to components, add attributes etc.

My conclusion is your front-end dev will need to know some Elixir/Phoenix to be effective. I am very new (probably not even a junior Elixir dev), but I am doing fine and enjoy it!

Any specific questions please let me know. I’ll do what I can to help.

Hope this helps!
Adam

5 Likes

Just a note that Tailwind is only the default for the Phoenix generator. As far as I know, there’s no Phoenix-related downside to replacing Tailwind with something else, if there’s something else that you or the front-end dev prefers.

As far as tips, I’d suggest:

  1. Set up auto-deployment to a preview environment to make it easy for both of you to see changes.

  2. Write a lot of UI tests (which of course are super fast with LiveView because there’s no need to involve a web browser).

  3. Use separate identifying attributes in your DOM nodes for different uses. That way, the two of you will be less likely to interfere with each others’ domains (front-end vs back-end). I reserve id and class attributes for CSS (even if you are using Tailwind, you might want to throw in an ID or class here and there), data-* attributes for JavaScript (even if you think you’ll only be using LiveView, you might need to have a little JavaScript eventually), and test-* attributes for tests for find DOM nodes (I mostly use test-role and test-id attributes for my testing).

2 Likes

First of all, thank you for your valuable answers. I already have some ideas on how to put them into practice.

Yes, that’s the feeling I had too. In fact we had already collaborated in the past on projects without LiveView and with versions of Phoenix prior to 1.7. There were no Components and it was easier to have a static HTML template that I integrated into Phoenix.

You have already done a lot by sharing your valuable experience. This sheds a lot of light on my uncertainties. Maybe do you have any suggestions for reading (books) to learn Tailwind CSS quickly?

Maybe I am wrong but for example this thread (LiveView phx-no-feedback without tailwind) seems to suggest that I won’t have forms validation feedback out of the box in LiveView if I drop the default tailwind.config.js plugin for assets management. I saw some workarounds in the thread but also in a Blog post (Phoenix 1.7 and Bootstrap 5 - Tutorials and screencasts for Elixir, Phoenix and LiveView see 3.3 Form validation), but in my opinion that is more work to do.

1 Like

Just to be clear, that post refers to integrating the feedback styling to all of bootstraps specific form input styles, but this is the only css rule you need to get basic showing/hiding of validations (it’s what we generated in the app.css of Phoenix 1.6 apps for example):

/* LiveView specific classes for your customization */
.phx-no-feedback.invalid-feedback,
.phx-no-feedback .invalid-feedback {
  display: none;
}

Then any container with the invalid-feedback class (or whatever you want to call it) would be hidden until the input is interacted with.

2 Likes

Thank you for this clarification. I will take note of it.

1 Like

You have already done a lot by sharing your valuable experience. This sheds a lot of light on my uncertainties. Maybe do you have any suggestions for reading (books) to learn Tailwind CSS quickly?

If you know CSS you should be able to pick up Tailwind quickly. I have not used any books to learn it, just the official Tailwind guides and google any questions I might have. I learn best by having a problem and then just solving it :grin:

This was a good turtorial that was helpful to me on Phoenix/Tailwind: Tailwind Navbar New LiveView 0.18 components - Tutorials and screencasts for Elixir, Phoenix and LiveView

2 Likes

A good front end dev should be able to re-organise elements and styling in either a heex template or inline heex - they don’t need to worry about event handlers, assigns, elixir code etc. Unless you’re happy to take on a lot of non-value adding work integrating their styling into your liveviews / components, you’re going to have to get them comfortable running Phoenix and editing directly in the project.

Communication is also key - define the high level UI “scaffolding” (e.g. hierarchy of controls) together, then you can work on the functionality and they can work on the styling.

FWIW - I really, really dislike fighting CSS. But I’ve been down the path of working with a standalone HTML / CSS developer and integrating their work. Learning Tailwind CSS and implementing directly off Figma designs was less of a pain than integrating their work. Best situation is definitely someone who loves the CSS stuff and can work directly in the Phoenix project.

I also have to say the quality-of-life improvements from the recent Phoenix component approach are amazing for the CSS-challenged, like myself. You’re definitely taking the right approach with learning about LiveView & Components. Tools like a Storybook for LiveView (https://phx-live-storybook-sample.fly.dev/storybook/welcome) may be helpful to build out and visualise the components you need. It’s much better to start out this way rather than trying to extract out big chunks of copy-pasted HTML/CSS later.

3 Likes