Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got to LiveView

fly.io

Post reply on HN
Print view View original

151–160 of 293 posts

Re: How we got to LiveView

#151

Post by mrkurt »

Omnipresent wrote: post #146
chrismccord wrote: post #2

Creator of Phoenix here. I'm happy to answer any questions folks have about LiveView, Phoenix, or Elixir in general. We've had some big LiveView features land recently with uploads and HEEx so now's a great time to jump in!

What resources would you recommend for someone new to Phoenix, LiveView, Elixir to get started on this stack?

This is a pretty good liveview tutorial: https://github.com/dwyl/phoenix-liveview-counter-tutorial

We also have a hiring project that's designed to ease people in to Phoenix + LiveView. We extracted this from a real app and tried to make it as simple as possible to work on: https://github.com/fly-hiring/phoenix-full-stack-work-sample

Re: How we got to LiveView

#152

Post by yeskia »

hervature wrote: post #12
chrismccord wrote: post #2

Creator of Phoenix here. I'm happy to answer any questions folks have about LiveView, Phoenix, or Elixir in general. We've had some big LiveView features land recently with uploads and HEEx so now's a great time to jump in!

Hey Chris, excellent work. Very excited about 1.6 and LiveView. If you update your Programming Phoenix, I would certainly pay again.

Yeah, would love to see an updated book to dive back in for 1.6.

Re: How we got to LiveView

#153

Post by dnautics »

erinan wrote: post #81
nightpool wrote: post #16

Earlier quoted context omitted.

I've tried to get into Phoenix a few different times, but I've always been stymied by the unfamiliarity of Elixir's syntax, especially codebases that made heavy use of composition and guard clauses, meaning that the business logic was scattered across a half-dozen different files which had to be read in sequence to understand a single web request. This was a big let-down from the (to my mind) very straight-forward na…

This has most likely to do with the codebase itself rather than with Elixir or Phoenix in your case. And having to go through a few files to understand how a request is handled is not out of the ordinary in an app, especially if it's grown over the years?

Tbh Phoenix has a lot of boilerplate and some... Opinions that make the codepath slightly more complicated (often for good reason... that might not apply to all use cases) in the default project.

For example:. What exactly is the distinction between an endpoint and a router?

Re: How we got to LiveView

#154

Post by chrismccord »

scraplab wrote: post #28
chrismccord wrote: post #2

Creator of Phoenix here. I'm happy to answer any questions folks have about LiveView, Phoenix, or Elixir in general. We've had some big LiveView features land recently with uploads and HEEx so now's a great time to jump in!

Hi Chris - this is superb, really pleased to see LiveView getting so much attention, and thanks for all your hard work. Can you talk a little about the current story with deployments and managing state across/during those? Obviously Erlang/OTP supports hot upgrades, but those are hard to design correctly and not supported by container/VM environments like Heroku and (I presume?) Fly.io.

Hot upgrades are a powerful and essential feature – when you have hard requirements for it. As you said, hot upgrades aren't simple and introduce a lot of work to get right. I like to tell folks, imagine you are building a pusher.com competitor, so your customers are paying for you to host active connections for their end-users. In this scenario, bouncing hundreds of thousands of connections for a cold deploy is a terrible offering because your clients are paying you or that reliable wire to their user's browser. Hot upgrades makes total sense here. Equally, if you're building a game server in Elixir, you likely don't want to teardown and rebuild your world state and bounce connected players.

So you opt-in to this complexity when you have a clear requirement for it. They other key point in this, is in either hot upgrade or cold deploy cases, you still have to design your stateful system to recover from complete restart. Servers catch on fire and things go bad sometimes, so the cold deploy approach of rebuilding the state on restart is not only completely viable by itself, but you're doing it anyway even with hot upgrades. Hope that helps!

Re: How we got to LiveView

#155

Post by chrismccord »

staticelf wrote: post #32
chrismccord wrote: post #2

Creator of Phoenix here. I'm happy to answer any questions folks have about LiveView, Phoenix, or Elixir in general. We've had some big LiveView features land recently with uploads and HEEx so now's a great time to jump in!

Are you guys looking into the Web Transport protocol for the future? Right now you have to tunnel the websocket connections over http2 and it will probably be the same for http3 afaik. I know there is this work in progress ( https://w3c.github.io/webtransport/ ) and websockets are probably fine for a long time but sooner or later (unless there is an update to websockets) it will probably be faster to just do normal h…

Phoenix Channels (which LiveView is built on) is transport agnostic, so as soon as we can open a pipe from the browser's JS environment, and listen on the server, we could have a `Phoenix.Transports.WebTransport`. All the existing user-land code and LV apis remain unchanged :)

Re: How we got to LiveView

#156

Post by iudqnolq »

mrkurt wrote: post #151
Omnipresent wrote: post #146

Earlier quoted context omitted.

What resources would you recommend for someone new to Phoenix, LiveView, Elixir to get started on this stack?

This is a pretty good liveview tutorial: https://github.com/dwyl/phoenix-liveview-counter-tutorial We also have a hiring project that's designed to ease people in to Phoenix + LiveView. We extracted this from a real app and tried to make it as simple as possible to work on: https://github.com/fly-hiring/phoenix-full-stack-work-sample

What sort of experience level are you hiring for? I've been teaching myself elixir and liveview over the past year for my first job (building dashboards for a non-technical nonprofit) and I've been hoping to transition to working somewhere technical but I have no idea how to do it. Thanks!

Re: How we got to LiveView

#157

Post by sschueller »

dugmartin wrote: post #14

I've used LiveView as it was meant to be used in a couple of small personal projects but in my latest (much larger) project I'm using it in a way that (given what I just read in this post) would make Chris' head spin. Basically I'm using it as a container wrapper for a large React app and keeping all the state on the client. This is only for the app pages on the site, the rest of the pages are either traditional "dea…

I don't know if would feel comfortable if my accounting apps state was mostly local and if my pc decided to take a nose dive I don't have the state on the server that assumed I have.

Re: How we got to LiveView

#158

Post by iudqnolq »

chrismccord wrote: post #122
mwcampbell wrote: post #95

> We also shipped a live_redirect and live_patch feature which allows you to navigate via pushState on the client without page reloads over the existing WebSocket connection. This is one LiveView feature I've deliberately avoided so far. The reason is that when you replace real page loading with client-side navigation using pushState, accessibility for blind users suffers. When a real page load happens, a screen read…

It's unfortunate there's no standard way to dispatch this kind of thing ARIA wise. Fortunately live navigation is opt-in, so folks can continue to use ` ` vs ` ` when needed. On the form submission side, we actually still have you covered within LiveView, because the server can instruct the client to do a plain redirect: def handle_event(save, params, socket) do ... {:noreply, socket} |> put_flash(:info, "It worked!"…

As far as I know you can't pipe that sort of tuple through those functions. Is that a future feature? It would be mildly convenient if assign({:noreply, socket}), ...) == {:noreply, assign(socket, ...)}

Re: How we got to LiveView

#159

Post by iudqnolq »

sergiotapia wrote: post #60

I'm leading the engineering effort of a stealth startup in Miami and we are using Liveview to power everything. It's very liberating. Heex does have it's warts and it is very new so expect to do some forum spelunking - but Chris McCord and Jose Valim are both very active and care about the product they are building. Usually things get fixed quickly. They are the heart and soul of the Elixir/Phoenix ecosystem so thank…

I switched to Surface for my project a few months ago. Have you tried both? Do you think Heex has any major benefits to make it worth slowly porting to?

Re: How we got to LiveView

#160

Post by dnautics »

whitepoplar wrote: post #42
tommica wrote: post #22

I've had such hard time wrapping my head around how to think in liveview - I've tried tutorials and building my own projects, but always end up thinking "am I doing this the right way"? How do other people structure their codebase, and what are the considerations they have? I think I'm trying to force my way of working with react and laravel, and lack some kind of a fundamental way of thinking to get my "aha!" Moment

Yes, I'm curious to hear about the patterns people use to structure their LiveView apps, particularly large ones.

I love liveview, but I hate genserver behaviour and liveview inherits some of the messiness of genserver behaviour.

This is a pattern that I started using for my Liveview pages: https://www.youtube.com/watch?v=HA4h0cajgaA

Not much help if you are looking for full LiveView apps, though. I haven't checked it out yet, but i hope surface addresses some of the structural organization issues.

Post reply on HN