ThinkingElixir Discussion: Mental models for your Elixir and LiveView code

Chat / Discussions
, , ,
1

In ThinkingElixir Podcast episode #40, we talked about the mental models we use when we think about writing our Elixir code or when thinking about our Elixir system. We also covered how we approach writing our LiveView code.

This topic is a public discussion place where we’d like to hear from you! What works for you? Did you make the mistake of trying to do it just the way you would in React? What tips work for you? How do you approach it now? Did any of our discussion help or resonate with you?

The LiveView discussion starts at 31:20.

9 Likes
2

Broken link?

3

the link seems fine but the episode is not up yet.
@brainlid the podast is great, thank you for that!

4

The episode is up now! That’s one of the challenges of trying to use ElixirForum as a place for public discussion. I would like to point people to this resource but you can’t schedule a post to “go live” at a certain time. Also, the other topic discussion link was deleted because a moderator thought it was a duplicate. :man_shrugging: This was an experiment. We’ll see how it goes.

5

Found this pretty useful, if only to punch down some imposter syndrome feelings and, while listening to thought leaders is very interesting, sometimes it’s nice to just hear people talk about the normal day to day kind of issues that can come up (“Hey it’s not just me that felt like LiveComponents aren’t quite there yet”). (Don’t mean this to imply you guy can’t be considered thought leaders! :wink:)

I have the same “I like it but…” feelings about Sasa’s changeset ideas, re: some validations are always wanted and some aren’t, and what feels the best when extracting duplicated validations out, etc.

I do think there is a lot of room to explore how phx apps should be structured. The basic generators feel natural at first blush, especially from rails, and are easy to teach but I am not 100% that they are the best way from a long term view. I do think they are correct for what they are trying to do, be a fast-runway-and-teacher.

Not sure how often you can use this exact format, but it might be interesting spin it into an “episodes review” episode every (few) months where you talk about if/how things you covered effected your practice.

6

Great discussion but I’m curious why you kind of glossed over Surface as a way to create more granular components:

https://surface-ui.org/uicomponents

Have any of you tried using it in this way in a significant project?

By the way, the new Surface Catalogue project is very cool as well:

1 Like
7

Could you give us a little more info about what you were intending please Mark?

For instance did you…

  1. Want to post a discussion about a topic then talk about the discussion that takes place in the thread in the podcast?

  2. Aim to do a live podcast which people can tune in to and join in via a thread on the forum?

  3. Post a thread about topics covered in an already recorded podcast? (If so, for what purpose? To make the discussion in the thread a follow-up topic in the next podcast or to simply spark a discussion about podcast topics covered?)

Usually we prefer that podcasters either post their episodes in the main podcasts thread thread or start a dedicated thread for their podcast and post all episodes in that thread. However if you want forum members to become involved in a more substantial way (such as per the examples above) let us know and we’ll see what we can come up with :023:

8

Thanks for the questions! We released an episode that wasn’t an interview, but instead a discussion around “the mental models we use for writing Elixir code” and a related topic of “the ways we think about and approach LiveView”. The goal was two things:

  1. Find a place where we could have community engagement.
  2. Direct people to ElixirForum as a place where they could engage with the larger Elixir community.

My alternatives for community engagement are a Thinking Elixir Discord or Slack, but that would be a community silo and I wanted people coming to Elixir to find and engage at ElixirForum. If this isn’t the right forum or approach, I understand. Is there a better way to go about that? One that would work better for your vision of what ElixirForum is and should be?

2 Likes
9

Yes! Surface is cool. I think it has matured a lot and it is definitely worth checking out.

10

I do think there is a lot of room to explore how phx apps should be structured. The basic generators feel natural at first blush, especially from rails, and are easy to teach but I am not 100% that they are the best way from a long term view. I do think they are correct for what they are trying to do, be a fast-runway-and-teacher.

Yes. In more complex applications, I’ve borrowed some ideas from the DDD (Domain Driven Design) community and use “aggregates”. In practice, it’s an embedded changeset (not linked to a DB table) that models a combined view of multiple data sources. Doing something like that requires a different context design than the one you see in generators. But I agree, the generators are a good place to start for people coming new.

I like the idea of an “episodes review”. Great idea!

11

Slightly off topic, but since this episode mentioned tailwind’s JIT, in my short experience, you need to patch the default webpack.config.js with this (at the very bottom):

.concat(devMode ? [
  new HardSourceWebpackPlugin(),
  new HardSourceWebpackPlugin.ExcludeModulePlugin([
    {
        // HardSource works with mini-css-extract-plugin but due to how
        // mini-css emits assets, assets are not emitted on repeated builds with
        // mini-css and hard-source together. Ignoring the mini-css loader
        // modules, but not the other css loader modules, excludes the modules
        // that mini-css needs rebuilt to output assets every time.
        test: /mini-css-extract-plugin[\\/]dist[\\/]loader/,
    },
])
] : [])

and follow the tailwindcssjit install instructions as normal.

Not sure if it’s worth phx PR or not, might have unforeseen consequences.

PS: JIT is totally worth it. No more long waits if you change css files.

I think the patch above is all you actually need but a really scrappy working repo is here GitHub - rktjmp/phx-tailwindcssjit to compare configs with if someone has trouble.

2 Likes
13

I haven’t had time to listen to the episode itself but from your description it doesn’t sound too dissimilar to what other podcasters are doing - where an episode is recorded and then a link to it is posted as an alert as well as in the hope it might spark a discussion. In that case our standard guidelines may be most appropriate, where you create a “ThinkingElixir Podcast” thread and then post links to each episode in that thread and include any points of discussion you want to raise :slight_smile: (you can link to individual posts in the thread as you can get the URL for a post by clicking on the timestamp in the top right corner of each post).

If you’d like to involve forum members in a more collaborative way (as per my post above) then we could look at what other options might be worth exploring. 1 and 2 in my post in particular could work well - perhaps in a video format (that also works as audio-only). However it’s something that would need to be made clear in the first post of the thread, i.e. that posts made in the thread may be reproduced in a video or discussed in a podcast - but let us know if this is something you want to try as we can help with the details. Perhaps you could have a main thread, and then dedicated threads for big topics that warrant such a collaboration? Again, just let us know if this is something you want to explore.

If you have any other ideas let us know too! :smiley:

1 Like
14

Thanks, my question was more along the lines of: Surface seems to solve the problem of creating small, granular components but you didn’t really acknowledge that - you seemed to imply that it just wasn’t “the LiveView way”, so is there some downside to using Surface in this way that I’m missing or is it perhaps that you just haven’t used Surface recently, or that you haven’t tried it on a “real” project?

I also noted that in your interview with Chris McCord, he expressed support for Surface and seemed to imply that he might adopt some of its approach into LiveView proper in the future.

15

Yes, it did sound like Chris McCord liked the approaches being explored by Surface and they might get incorporated into LiveView. That’s super cool!

I have used Surface on a significant project. At the time, surface was very new. It was even pre-release. So after some time (a month or so), I switched it out for regular LiveView and components. Mainly the issues I had were around dependency conflicts. Surface would require master branch of LiveView and that would break things on our production app as it wasn’t fully ready.

I like Surface, but personally I don’t have a need for it at this time. A lot of my “small, granular components” are simple helper functions that render an ~E block with a static component. I use TailwindCSS for styling so that’s handled there too. There aren’t that many actual “live” components, but when there are, that API works well enough.

1 Like
16

For me, this is one of your most valuable episodes. Prompted me to go back and listen to the Sasa Jurik interview. Now my schemas are all organized within their own boundry - a flatter organization that I think will be easier to maintain over time.

2 Likes
17

I finally had time to listen to the episode.

I really liked the workbench metaphor. I try to recapitulate as I understood it:

  • a couple of workbenches each with a set of tools (modules)
  • on them binders with some sheets of paper (functions)
  • little pixies running from bench to bench (processes)
  • carrying blocks of wood (data)

The pixie’s duty is to transform the block of wood into something useful, say she wants to create a shiny wooden ball. I think she needs some instructions how to do that.
She gets those from a gremlin (coordinator) sitting on a shiny throne at the boundary of the workshop.

# instructions for pixie 4711 issued by gremlin 0815
block_of_wood
|> WoodturningBench.shape_to_ball
|> WoodturningBench.polish

That’s easy, we can have thousands of pixies doing that in parallel (not really, but they are so fast, that it seems like it) and we can have the fairies of the QA division follow the same instructions. And we know, if they are happy with their result, we’ll be happy with what the pixies do in production.

So everything is good. Until the ogres at management decide, that revenue has to be increased. The orks at marketing have the solution: Lets sell not just shiny balls, but red shiny balls.

The gremlins add

...
|> Paintshop.paint(:red)

to the instructions. Everything still works well and revenue increases as the customers are enthusiastic about the red shiny balls. But not for long. The paint peels of from the balls and customers are furious and demand refunds. So we need a quick solution. Its easy. We just have to add a primer.

...
|> Paintshop.add_primer
|> Paintshop.paint(:red)

But wait, the fairies at QA notice that the shininess has decreased. Someone reads the instructions of the primer. It has to dry for an hour! So now the pixies have to grow some gremlin ears: after they applied the primer they tell another gremlin to wake them after an hour, so that they then can apply the paint. First tests with this approach in :dev are promising, but the QA division is not happy. They are not allowed such long running jobs. The ogres decide to increase revenue even more by reorganizing (dissipate) QA. The product is perfect and shiny, no complaining fairies anymore, so they lived happily ever after with ever growing revenue … NOT (some fatal flaw creeped in and the whole workshop got bankrupt.)

2 Likes