3 ms·

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 d

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

whitepoplar 5y ago
Yes, I'm curious to hear about the patterns people use to structure their LiveView apps, particularly large ones.
- dnautics 5y ago
  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 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.
sodapopcan 5y ago
I totally get the "Am I doing this the right way?" feeling, especially coming from Rails where everything was so opinionated and wanting to stay idiomatic. Phoenix, while it does have opinions, is far less opinionated in the sense that it doesn't do its darndest to force you into certain conventions (for example, if your module name doesn't match your file name, Phoenix won't complain). Its generators do try and push you toward using good DDD practices (which is my opinion is a GREAT thing), but of course the generators are completely optional. I don't have experience writing large LiveView apps but I would say that if you are familiar with any component-based frameworks (like React), I would take a look at SurfaceUI[1]. It simplifies a few "gotchas" in LiveView (though I would say they are very minor gotchas and worth learning about at some point) and gives you a component-rendering syntax more like React. Once you get going, you'll learn that LiveView doesn't have all the headaches that come with bigger React apps (like having to memoize functions or comparing props to avoid a re-render and whatnot). The recent release candidate for Phoenix 1.6 has made strides for a cleaner component syntax, but if you're having trouble with LiveView, Surface might bring some familiarity. [1] https://github.com/surface-ui/surface https://github.com/surface-ui/surface
dv35z 5y ago
Influenced by your comment and others below, I created a shared spreadsheet where we can share our code structures & patterns informally & learn from one another. https://docs.google.com/spreadsheets/d/10gCxVJyrme6Rv-LepqIdNKAnKHky4AGSIZAItH6CwoE/edit https://docs.google.com/spreadsheets/d/10gCxVJyrme6Rv-LepqId... Once there are enough contributions, perhaps a community member could write a blog article summarizing the major patterns - the use cases, patterns, benefits & drawbacks. Don’t be shy!

whitepoplar 5y ago

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

dnautics 5y ago
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 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.

sodapopcan 5y ago

I totally get the "Am I doing this the right way?" feeling, especially coming from Rails where everything was so opinionated and wanting to stay idiomatic. Phoenix, while it does have opinions, is far less opinionated in the sense that it doesn't do its darndest to force you into certain conventions (for example, if your module name doesn't match your file name, Phoenix won't complain). Its generators do try and push you toward using good DDD practices (which is my opinion is a GREAT thing), but of course the generators are completely optional. I don't have experience writing large LiveView apps but I would say that if you are familiar with any component-based frameworks (like React), I would take a look at SurfaceUI[1]. It simplifies a few "gotchas" in LiveView (though I would say they are very minor gotchas and worth learning about at some point) and gives you a component-rendering syntax more like React. Once you get going, you'll learn that LiveView doesn't have all the headaches that come with bigger React apps (like having to memoize functions or comparing props to avoid a re-render and whatnot). The recent release candidate for Phoenix 1.6 has made strides for a cleaner component syntax, but if you're having trouble with LiveView, Surface might bring some familiarity. [1] https://github.com/surface-ui/surface https://github.com/surface-ui/surface

dv35z 5y ago

Influenced by your comment and others below, I created a shared spreadsheet where we can share our code structures & patterns informally & learn from one another. https://docs.google.com/spreadsheets/d/10gCxVJyrme6Rv-LepqIdNKAnKHky4AGSIZAItH6CwoE/edit https://docs.google.com/spreadsheets/d/10gCxVJyrme6Rv-LepqId... Once there are enough contributions, perhaps a community member could write a blog article summarizing the major patterns - the use cases, patterns, benefits & drawbacks. Don’t be shy!