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.
177 karma · joined May 23, 2012
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.
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.
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!
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.
Anybody had similar impression?
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.
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.
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.
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.
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.
Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header.
After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run.
Only then you can see that you need to format dates - your rendering function should be responsible for formatting.
Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date".
Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm)
Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value.
In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous
Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.
Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.
[1] Creating complex type definitions for more generic components is hard and require knowledge about internals.
And I agree with you. Rich has strong opinions and he likes to stir some discussion. And that's fine, he always responds with nuance and mutual respect. Problem is when community parrots his one liners. If I had a nickel for everytime I got yelled with "vdom is pure overhead!" or "jsx is an abomination, my templates are pure html".
In the end I'm not even sure if it is something specific about Svelte, or just any non-react solution has to bash React loudly.
Internationalization API is a great example. We should leverage the platform but we can’t.
We found that rx.js is bad for coordination. I think coordination is a big part of services in angular UI's. You need to fetch some data, wait for it, ask for different thing, maybe change some state. Promises and await are great for this and especially await syntax is readable (go channels could be even better). In rx.js you had to nest multiple switchMaps for dependant queries and for state - you either produce state as a stream result or you put some `tap` or `subscribe` with `takeUntil`.
But rx.js shines with more complex user interactions - drag and drops, brushes, interactive forms (angular has nice, reactive form api). We even put some state machines inside streams, so input signals produced events. and we had `scan` operator that manipulated machine.
My personal issue with rx.js is that BehaviourSubject is leaky - you can do anything to it, and break it's property of 'always has a value'. It is nice if your service is a reactive value that you can inject and transform or render using async pipe. But you need to be careful what operators are you using on it.