ThinkingElixir Discussion: Mental models for your Elixir and LiveView code

Broken link?

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

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. This was an experiment. We’ll see how it goes.

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! )

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.

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:

https://github.com/surface-ui/surface_catalogue

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

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?

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

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!

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: How to setup Phoenix Framework and TailwindCSS-JIT · GitHub to compare configs with if someone has trouble.