brainlid
ThinkingElixir Discussion: Mental models for your Elixir and LiveView code
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.
First Post!
a8t
Most Liked
brainlid
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:
- Find a place where we could have community engagement.
- 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?
soup
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.
AndyL
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.
Last Post!
Sebb
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.)
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"