Kinda? I’m starting to regret using auth as an example! Dan recommended Sam’s talk to you. He explains that with better examples and more clarity than me.
Sure! In some methods of authentication, like OpenID, not only your client need to present some UI, but also you need to prepare some endpoints on the backend to handle full flow of authentication. You probably also need to provide some parameters to those endpoints and methods inside.
So again, you want to add one thing “auth”, but need to add code in multiple places in your app. Server components promise to encapsulate that. Idea is that you can grab a component from npm, and it will handle all of that orchestration for you, and component will be your only one interface, so all configuration can be passed as props (of course it will be taken from your env/secret).
The promise is that you can encapsulate inside a components both client and server code.
Value proposition is “components for server”. But it’s worth to take a step back first.
What is value proposition of react component in comparison to older “mvc-inspired” frameworks? That you can drop a component in your code and call it a day. Don’t need to wire up separate controllers, models and views. Just one thing.
Now, if you want to add “auth” to your app (in react meta framework like next) you need to add component and probably add some routes and inject some middleware. With server components, you just add one component somewhere in the root of your app. Just one thing.
All that over the wire format, suspended data fetching etc, are a result of solving that problem and keeping in mind that those components are slightly different. It takes more work, but in return we can interleave both types of components nearly freely.
Reminds me of karet [0]. I used it with great success for making interactive visualizations. This duality of passing a value or passing a stream of values was great.
Over the years I took part in few similar discussions. Almost every time argument against regulations was “but alcohol prohibition in USA made things worse”. I don’t have knowledge, but intuitively I’m not sure if it’s really that bulletproof argument. Have someone any thoughts? How to approach that critically?
I had a lot of fun using squint with solidjs. It pairs so well with minimal, focused libraries. Maybe it doesn’t give you any superpowers but make code a little cleaner and steer you away from few traps.
On my “nerd snipes” list I have project that merges squint and hwy framework. It sounds like bleeding edge for the sake of bleeding edge, but on the other hand sounds so compelling!
Don’t you mix up „Almost Lost” with „Lost World”? qztourney6 is kinda linear and rail heavy. And wasn’t in standard map pool too long. But I admit, I had a lot of fun playing 2v2 there!
What’s your experience with StarLite IV? I’m thinking about buying it for heavy note taking - neovim/obsidian/browser (Google docs and excalidraw). What battery life I can expect? Is keyboard nice to type? Is stuff like sleep, Wi-Fi auto connect and bluetooth headphones really solved?
I was helping with an application that used htmx and had two issues. I’m wondering if anybody had similar experience and if these issues are from misusing technology or maybe there’s some ongoing work to address them.
1. A lot of custom middleware in controllers to decide if endpoint should return HTML for whole page or only fragment that htmx needs. On the side of htmx that sounds simple but it is something that probably every project using htmx have to reinvent.
2. Bookkeeping around `hx-trigger`. If UI is getting complicated, many elements need to react to external changes. Instead of reading some state and hope that framework will schedule updates, I have to manage a list of events to react by hand.
I was growing up in Poland in the height of John Paul II cult. I was raised in atheist family and I was getting some tidbits about my grandfathers brother who was sexually assaulted by a priest.
Today it sounds a little bit silly but that SNL performance was the validation I needed to navigate my environment outside my home.
Now I learned a lot about issues in Catholic Church and I understand this stuff better but I’ll be forever grateful for this small gesture of solidarity. Even if it wasn’t directed at me.
Is it possible to get on Phoenix nested controllers? Like in remix.run, where for each route segment we get one controller/view. It’s really generalised version of layouts.
When I was looking into Phoenix all routes, no matter how nested, had to resolve to single controller. That meant that controller for path `/user/settings/privacy` was also responsible for getting data to display users sidebar.
> If I wanted to build a single page application, I would absolutely, 100%, write it in Elm.
I find this interesting, because SPAs in Elm are more like exercise for the reader. If you look how NoRedInk uses Elm you will see that’s more like one “app” per REST controller [1]. Do you have some experience with specific solutions that you could share?
What's funny, rtfeldman uses case expression with numbers in his (in OP's blogpost) praised library elm-hex, so it's not the problem of numbers vs variants. Only negative numbers are the problem.
There’s still https://www.lenstip.com/. English version of Polish site optyczne.pl. What’s funny, team from this site criticized dpreview for being not scientific enough.
Could you define correctness in this context? I'm asking because I don't believe that you can achieve correctness using Elm type system. I don't see how you can encapsulate i18n rules inside Elm type definitions. Maybe something like Coq could do this ...
You can't express something like "if passed 3 as group size, integer part of the number should be represented as string with separators between three digits". Even in Elm that's something that you need to handle not in type system but in runtime code.
What is more - many core packages are just this - typed layer over browser API. elm/regex introduce barely any type safety. It assumes that browser API is "correct".
> Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.
I often see this response from Elmers but really I don't understand the point of it. I responded to claim that Ports solve all problems. I provided good, real example where Ports are a bad solution. In return I was scolded that I don't understand software engineering.
I don't jump into elmconf and complain or demand changes. I just provide my take on the discussed issue. And to be frank, I think that's very valuable take for someone who decides if Elm is good for them. That kind of information is not present on elm homepage and is not obvious for new users.
> but it also seems to be a natural consequence of "up-typing" an entire eco system.
Reimplementation of i18n API in Elm would make sense only if benefits from types could outweigh robustness of browser implementation. Due to not very expressive Elm type system I really doubt that. You can’t capture intricacies of i18n in Elm type system.
I have more confidence in already tested and used by millions API in the browser than in reimplementation in niche language.
Elegant solution would be if I could write well typed layer that calls browser API. Low bar of entry would drive adoption and in effect real world test. But that’s not possible anymore.