🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:07 jgaz joined
SmokeMachine I don't know if anyone would be interested, but I've been playing with HTML::Component (probably it should be called HTMX::Component because I'm using htmx on it), where you can define components and on it's methods it can define the endpoints and with Cro (I also have code to use with hummingbird, but it's still failing). Can anyone give me some opinions/suggestions? github.com/FCO/HTML-Component 00:31
00:32 jgaz left
aruniecrisps @SmokeMachine would it be possible to use html syntax? 01:36
SmokeMachine Yes, but it would use some of these benefits of that, like the type safe html and the automatic `endpoint` 01:38
aruniecrisps gotcha 01:40
yea i think this is cool
Voldenet it'd be great if with nqp-js you could have both client and server side rendering 01:43
while it's not even certain future, it may be necessary to have some notion of lifetime in components 01:44
like vue/svelte/react have mount/unmount and update lifecycle hooks 01:48
usage of it in server side is limited, server side mostly requires event handling and propagation 01:49
SmokeMachine We have something “like that” for Raku-js (that’s old…) github.com/FCO/MemoizedDOM 01:50
that’s not all that limited when using htmx (as I’m doing on HTML::Component)
The components do not keep alive on the server (on my example it does only to simulate db…) 01:54
Voldenet I built something similar that kept the whole dom tree on the server (with events and similar things) and only handled client state with events 01:58
so the server used to mount the tree to received client state, process whatever and return the resulting state 01:59
SmokeMachine I did that too (github.com/FCO/p6-react) that uses websocket and keep the tree on the server… 02:00
Voldenet I believe it's a bit different, because it doesn't reuse the same instantiated dom tree for all clients 02:03
while using lifecycle events
though it probably was more brittle than simply using react on client side with pure rpc 02:04
SmokeMachine HTTP::Component does not store anything. The browser that (using HTMX) asks what component to use and that method to call, the server load the component using a method from the component (that can, for example, load data from DB), calls the method and, based on the endpoint configuration can return what the method returned, redirect somewhere or return the component html…
Voldenet So in the example components share the same state for all clients? 02:09
SmokeMachine On that example, yes… but just because TodoList is a singleton… (but it also have an id… if you make it able to store and load multiple TodoList, each user could have different todos… each object has its own state… 02:12
Voldenet I guess I can imagine using db for it, but 02:14
SmokeMachine If someone is going to test the example, it takes very long for the first request (there is a dynamic require taking too long) but it gets faster after that 02:15
Voldenet this would probably need very specific type of app to be viable 02:16
SmokeMachine I think that would have the same weaknesses and powers as htmx… 02:18
Have you played with htmx? 02:19
Voldenet I have used intercooler.js about a decade ago and it was weird approach even back then 02:20
replacing parts of dom tree (and needing to know the full view state) makes some things difficult to implement compared to pure js with rpc 02:30
I'm only wondering how far this approach can go before it's too complex to debug 02:32
SmokeMachine With htmx you don’t need to know the state of the whole page. You only get the component is going to change… 02:33
Voldenet but if you have some top level component property (like language or style), you'd need to fetch the full state, so you can re-render everything from the top 02:35
at the end the biggest problem is complexity of the state, it's more trivial if your approach is data-centric (GET /todo-items, GET /todo-items/1 etc.) and not component-centric 02:40
02:41 hulk joined 02:42 kylese left
SmokeMachine But on my case, you would just do: GET /TodoList/1/add-todo { description => “blábláblá” }. It creates the new todo and redirects to / (this is not using htmx for testing… 02:50
And each component stores its own state/data 02:51
Voldenet But keeping it in server's memory could be the problem then 02:54
SmokeMachine What kind of data you are thinking about? 02:56
Voldenet Imagine 1000 todo items per list and 1000 todo lists per user 02:57
or any state you'd normally keep in react apps, overgrown tree of properties becoming 100MB of memory 03:00
Ofc, not all apps require this much state/interaction, so what I said earlier applies, you need specific type of app 03:01
SmokeMachine In the caso of the 1000 x 1000 todos, all data would be on db, so that wouldn’t be a problem… 03:12
03:15 hulk left, kylese joined 03:30 kylese left 03:36 kylese joined
tbrowder__ leont: yes, it is probably an author test, but i don't usually try to make the distinction. 03:37
04:37 vlad__ joined 05:00 vlad__ left 09:54 vlad joined 10:06 CIAvash joined 10:36 vlad left 10:49 CIAvash left 11:25 kst left, kst joined
El_Che lo 11:28
11:28 El_Che left 11:30 El_Che joined 11:41 Sgeo left 12:09 vlad joined 12:24 vlad left 13:10 vlad joined 13:21 derpydoo left 13:33 vlad_ joined, vlad left 14:13 MasterDuke joined 14:38 sena_kun joined 14:52 vlad_ left
leont tbrowder__: cleaned the commits up a bit and released it :-) 14:56
15:06 vlad joined 15:20 sena_kun left 15:37 vlad left 16:17 vlad joined 16:29 derpydoo joined 18:02 MasterDuke left 18:16 MasterDuke joined 18:48 vlad_ joined 18:49 derpydoo left, vlad left
tbrowder__ leont: thnx, sorry about the messy commits 19:02
19:02 jpn joined
Voldenet SmokeMachine: Even with db, effectively server becomes all the browsers that use the app at the same time, it scales horribly for multiple clients 19:08
19:09 jpn left, itaipu left
Voldenet with js client app becomes distributed node that only needs to synchronize data, rendering and interactions are separated from data 19:10
so you use client's memory for everything instead of server's memory
(or db storage, which is some kind of memory too) 19:11
19:22 itaipu joined 19:33 vlad_ left 19:35 MasterDuke left 19:37 merp left 19:40 jpn joined
patrickb Can I type constrain a return value to a two element list of Int and Str? `(Int, Str)` didn't do it. 19:40
19:44 jpn left
ugexe "only needs to synchronize data" - not having to synchronize data is a pretty big win though 19:44
list is untyped 19:45
i'm not figuring out a way to do something like --> @_ [Int $, Str $] though 19:48
japhb ugexe: Maybe `where :(Int, Str)`? 19:54
(That's just a guess, haven't tested it) 19:55
20:19 bent_fingers joined
antononcube weekly:rakuforprediction.wordpress.com/20...s-zombies/ 20:27
notable6 antononcube, Noted! (weekly)
20:33 abraxxa-home joined 20:34 Sgeo joined
Voldenet if you need to return multiple values, consider a class, it's not that verbose 20:35
`.count .description` and similar sound more reasonable than `[0] and [1]` 20:39
21:00 sena_kun joined
leont Now, I really should get the new SQL::Abstract out, been saying that for two weeks now 21:54
22:14 bdju left, bdju joined 22:35 jpn joined 22:39 jpn left 22:56 sena_kun left 23:33 abraxxa-home left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!