00:32 summerisle_ left 00:33 summerisle joined 01:36 Pe_Elle joined 01:50 Pe_Elle left 02:05 Pe_Elle joined 02:23 Pe_Elle left 02:39 Pe_Elle joined
SmokeMachine would someone like to also play with components using Cro and Red? github.com/FCO/SmallComponentTest/...nt-test.p6 03:08
03:41 Pe_Elle left 03:51 Pe_Elle joined 04:05 librasteve_ left 04:54 Pe_Elle left 05:05 japhb left 05:07 Pe_Elle joined 05:09 japhb joined 06:10 Pe_Elle left 06:24 Pe_Elle joined 07:26 Pe_Elle left 07:33 Pe_Elle joined 07:57 guifa left 07:59 guifa joined 08:35 Pe_Elle left 08:40 guifa left 08:49 Pe_Elle joined 09:59 sena_kun joined 10:22 Pe_Elle left 10:33 Pe_Elle joined
librasteve SmokeMachine: I am replying on this channel since it is less noisy (yet) than the main raku-irc 10:43
thanks for the opportunity to take a look at your small component test, which, it seems to me is a quick "working sketch" of how you see HTML::Component going (?) 10:44
it is very useful to help shape my ideas in this area to see how much Red can do in the Model arena - so in fact I think my "ideal" Cro WebApp will be built in Red (even though jnthn has been going in the Django direction with the Cro / data modelling work - which has the advantage of incremental schema changes btw) - so this means my opinion right now is to enjoy the simplicity of Red at the potential cost of 10:48
having to work out how to do data upgrades and migration later (which you may already have, but I haven't looked closely enough)
OK - that said, my model of "how to do web in raku right" is currently lurking here github.com/librasteve/raku-HTMX-Ex...te.rakumod ... this is very very early design thoughts and some things here are missing such as the render method will be a multi that you can pass a body as Str or a Callable since HTML stuff is usually assembled the same way as a CroTmp macro 10:55
there is quite of lot of weird stuff going on in my head like "I think that the layout and style aspects of CSS should be specified via separate chains of roles does" so if that is too odd for you then I fully understand 10:57
so - the core points are that a Component (here called an Island) is like this:
class Island does Render { has Style $.style; has Layout $.layout; has Content $.content; has Model $.model; has Routes $.routes; } 10:58
so your model stuff fits right in here
must hop will take a deeper look later
11:36 Pe_Elle left 11:50 Pe_Elle joined
SmokeMachine librasteve: I think I’ll need some time to understand what you wrote. But about DB migrations, we plan to bring that to Red too… if you’d like to help on the discussion of how: github.com/FCO/Red/issues/15 (I also have done a presentation on Vegas trying to explain the plan and get help… but I wasn’t very able to explain that neither to grab people’s attention… (I think that was my worst presentation)) 12:06
12:51 Pe_Elle left 12:59 Pe_Elle joined 14:01 Pe_Elle left 14:06 Pe_Elle joined 14:14 guifa joined 14:57 Pe_Elle_ joined 15:00 Pe_Elle left 15:10 Pe_Elle_ left 15:33 Pe_Elle joined
librasteve good - sorry this is very early in my thought process ... that said, I think that your HTML::Component can fit well into my roles and so on ... if we can agree a common API ... since the business end of a component is the HTML / CSS / JS that it produces, I think that the API could be as simple as: 16:06
subset Html of Str; subset Css of Str; subset Js of Str; class Content { has Html $.html is required; has Css $.css; has Js $.js; } subset BodyCall of Callable; #<== returns Content object (not sure how to specify that) role HTML::Component::API { #| the render multi method takes a body (Str or Callable) multi method render(Content $ -> Content) { ... } multi method render(BodyCall $ -> 16:18
Content) { ... } } class HTML::Component does HTML::COmponent::API { ... #your simple code example would go here }
sooo _ I think the only thing this needs you to change is to rename your method Str to multi method render and to be prepared for it to take a Content body and, at minimum "pass through" the CSS and JS pieces provided (if any). 16:28
(apologies if this is scrambled on the IRC side!)
SmokeMachine Sorry, why would render (that if that’s something that need to be implemented by every component, I think it would more sense to be called RENDER) would receive anything? Shouldn’t it use only data from the component itself? 16:35
16:37 Pe_Elle left
librasteve good question 16:38
The idea of an Island is that it is an independent piece of web functionality that may have its own modek, views, routes and so on - think of a shopping cart maybe. Unlike a contiguous piece of HTML, 16:41
(oops hit return too early)
In this example you may have a small "icon" view that appears on every page (where the number of items is dynamically set bu the model), a box (maybe a modal) that pops up when you are on a product page and then some full page views that step through the payment and delivery. 16:43
Thinking of the icon, maybe that sits in something like <head><nav><ul><li>...</li><li><span id="icon"></span></li></ul></nav></head> 16:45
so in my early thinking, we want a systematic way to collect HTML so that ALL we need to do is specify <span id="icon"></> and that our shopping cart Component provides this when we ask it for the icon view. So the idea is that Components can be Nodes in a tree and that in this case we have a three levels of the tree - Head, Nav and Cart - so I am proposing that render of Head allows Nav to be passed in as its body 16:49
and that render of Nav allows Cart to be passed in as its body.
16:51 Pe_Elle joined
so in a simple HTML::Component - all it MUST do is return some HTML, but it MAY also take a body to allow it to be a participant in a wider framework ... as I have said this is very poorly thought throught so far and needs some time to do a proper design and prototype. 16:54
this is the purpose of a Cro Template macro cro.raku.org/docs/reference/cro-we...tax#Macros 16:55
also
SmokeMachine But in case of the component, shouldn’t the data used on the component be passed to it in construction time, and render only user the obj’s data to prepare the html? 16:58
librasteve SM: you have some excellent questions ... sorry to duck them but I am embarrassed how poorly thought out my ideas are ... and I am on a deadline to write my advent post ... can I suggest that we aim to do a prototype collaboratively. I think I need to spend a couple of days getting my ideas straight (as well as day job) so can revert back hopefully with my ducks in a row around the middle of the week 17:04
SmokeMachine I mean, you can crease that icon as an object (Icon.new: :src</bla/ble.jpg>) and pass that to shopping cart (or the tree), and the render of that tree would be to just visit every node and call it’s render. Each component could have its own children… 17:05
Sure! Sorry for keep interrupting you
librasteve no problem - its really an interesting problem and (with HTMX and Cro) I think we have a great opportunity to define best practice - ;-) 17:06
so I cant resist the interruptions ... 17:07
I suppose the call sequence is Site => Page => Head => Nav => Cart ... in each case the parent is a node in the tree with children (although Head and Nav is reused in most Pages) and can aggregate the HTML / CSS / JS back up ... so I think you are right that you can just call Project.new.render and get a new site dir back 17:13
17:45 guifa left 17:54 Pe_Elle left 18:08 Pe_Elle joined
SmokeMachine in my todo example, the todo objects already are a kind of island... when you click on the checkbox it calls the toggle method (on the server) and it rerenders only the affected todo comoponent... 18:29
19:22 Pe_Elle left 19:37 Pe_Elle joined 20:42 Pe_Elle left 20:56 Pe_Elle joined 21:17 Pe_Elle left 21:27 Pe_Elle joined 22:29 sena_kun left 22:30 Pe_Elle left 22:44 Pe_Elle joined 23:20 summerisle is now known as eof 23:47 Pe_Elle left 23:57 Pe_Elle joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!