Customize Elm init function ?

[YievCkim]

Hello,

Is it possible to customize Elm.MyApp.init with Djelm ?

By example If I want to change the node, use port or add more flags etc...

I saw Djelm created ts files for each application in djelm_src. But comments suggest to not change this file.

For flags is not a problem to do that from the Django view. But it would be helpful to have the possibility to add port for websocket, SSE etc...

Having the possiblity to specify node could be helpful for pre-rendering on server side.

[Confidenceman02]

Hello hello!

Is it possible to customize Elm.MyApp.init with Djelm?

No it's not. The init is wired up on program creation to just accept the model and not much else.

By example If I want to change the node, use port or add more flags etc...

Not configurable currently but I definitely have thoughts around using ports!

There's definitely design patterns to provide hooks in to the hydration code so you get access to the life cycles of the program. That's were you would be able to setup ports, have access to the html node, do other javascript stuff etc etc.

These were secondary thoughts however and not critical to getting Djelm up and running in a useful way. So not quite priority for now.

I saw Djelm created ts files for each application in djelm_src. But comments suggest to not change this file.

Yep! These files are highly likely to change or even disappear completely but you could just ignore the warning.

All this to say, please hack around as much as you need to get something working for your situation. I would love to see any ideas and experimentation you do, so make sure you share them! 😄

Having the possiblity to specify node could be helpful for pre-rendering on server side.

Interesting! Could you elaborate more on this?

[YievCkim]

There's definitely design patterns to provide hooks in to the hydration code so you get access to the life cycles of the program. That's were you would be able to setup ports, have access to the html node, do other javascript stuff etc etc.

Ah that will be very cool to have this.

These were secondary thoughts however and not critical to getting Djelm up and running in a useful way. So not quite priority for now.

I do understand. That said, using the port system is something I have to do quite often with Elm, I find. For web socket or local/session storage access by instance. I hope that will see the light of day, one day. I am agree that's not critical, though.

Yep! These files are highly likely to change or even disappear completely but you could just ignore the warning.

Are we agree that these files are created only at the app creation time and not modifed after that ? In this case I think it's possible to setup web socket or local storage and setup port in Elm here. Am I wrong ? When you mention changing or disapearing do you mean after a Djelm upgrade ?

For now I didn't have this need, but as I said that's something I need to do quite often.

All this to say, please hack around as much as you need to get something working for your situation. I would love to see any ideas and experimentation you do, so make sure you share them!

I thought about using web sockets at some point on my project to update user stories when they are concurrently updated but I left that out for now and refresh the story when the server returns an error about this (it's a specific error on server side and it's implemented directly in the model so it was quite easy to implement). So it's not a "real time" behavior but it's acceptable for the scope of my project .

Now the hard part 😄:

Having the possiblity to specify node could be helpful for pre-rendering on server side.

Interesting! Could you elaborate more on this?

What I have in mind is to use django templating to pre-render html page with data and having Elm swapping data on the fly when it is loaded. A kind of SSR in some way but I am not an expert of that and I am not sure about how Next or Elm-page do that. Maybe it's more complicated to implement this with Djelm than I think. Next and Elm page run on node, which may make things easier because the code is directly interpreted by the server.

For example say we have a e-commerce app. We could serve a page with a bunch a products from django and after the javascript is loaded swap this collection of product with the ones in the Elm model.

In this way, it would be possible to access the content without having to interpret the javascript. This could be useful for indexing by search engines (SEO), and would avoid flicking during page loading. I've noticed this flickering on my project when I switch from one page/app to another. It's not very annoying on my project (its purpose is mainly to test Djelm and have a Django project to show on my Github) but it could be nice on a more professional project.

I am not sure If I was clear, let me know.

[Confidenceman02]

Are we agree that these files are created only at the app creation time and not modifed after that ? In this case I think it's possible to setup web socket or local storage and setup port in Elm here.

They are set up at program creation. So for every program you add, you get one of those *.ts files.

When you mention changing or disapearing do you mean after a Djelm upgrade ?

Yes that's right! For now they are safe to modify, in fact one company that uses Djelm does exactly that! They load 3rd party javascript, do ports and a lot of other stuff from there.

They do that with the understanding that it will likely change in the future, I would like to have a more robust way to support js hooks into djelm lifecyclesl ports etc. Ideally you wouldn't even see those *.ts files, but they are there because it's convenient for now.

What I have in mind is to use django templating to pre-render html page with data and having Elm swapping data on the fly when it is loaded. A kind of SSR in some way but I am not an expert of that and I am not sure about how Next or Elm-page do that. Maybe it's more complicated to implement this with Djelm than I think. Next and Elm page run on node, which may make things easier because the code is directly interpreted by the server.

Yep I know exactly what you mean.

Next uses an implementation for React Server Components(RSC).

Elm-pages uses a clever hack on the compiled Elm code. Essentially they run the app on the server and only call the view function. A piece of code is also injected in to the compiled code so that when the view runs in the server, the kernel code also spits out the VDOM representation which is then prepared for sending down the wire. Once it loads on the client the client version of the app rehydrates it. From then on it works as an SPA.

It is incredibly complicated.

For example say we have a e-commerce app. We could serve a page with a bunch a products from django and after the javascript is loaded swap this collection of product with the ones in the Elm model.

Elm-pages does make this possible! That's be a better tool than Djelm for this type of stuff.

I've noticed this flickering on my project when I switch from one page/app to another

It depends on how you have set up your pages and what exists on them but definitely check out HTMX. That might help if not completely solve that problem. You can even load Djelm programs with it!

Djelm also lazy loads programs, so for the best performance you could add all the include tags on the base html page of your app. That way the hydration code is already loaded ready to go for all your programs.

Djelm is designed to be used specifically for highly dynamic UI. Stuff you would need to load javascript for anyway. With the majority of static content rendered by django. You can totally use it for all of the UI but achieving SSR on it is not currently it's core focus.

Widgets for example is something Djelm is highly optimized for. I recorded a video creating a Django form and use a djelm widget to replace the widget django gives you. It's a great use case for Djelm.

https://www.youtube.com/watch?v=jX1NDIUv9SU

My opinion is that anything on your page that is static, should be server rendered with django, and the parts that are highly interactive, that's a job for Djelm!

Having said that! :)

There is a future for Djelm and Proper server side rendering! But it is incredibly early days, so nothing to show for now :)

[YievCkim]

It is incredibly complicated.

Ah ah I suspected as much. Thinking about it, I came to the conclusion that js had to be executed somehow on server side, indeed.

It depends on how you have set up your pages and what exists on them but definitely check out HTMX. That might help if not completely solve that problem. You can even load Djelm programs with it!

Djelm also lazy loads programs, so for the best performance you could add all the include tags on the base html page of your app. That way the hydration code is already loaded ready to go for all your programs.

Thanks ! I am going to look that.

My opinion is that anything on your page that is static, should be server rendered with django, and the parts that are highly interactive, that's a job for Djelm!

Thanks for the video ! I'm just about to tackle the forms in my app. Perfect timing !

That said, I'm having trouble seeing how Elm can integrate dynamic parts with static parts rendered by the server. Indeed, an Elm application works with a single model and has a single view. It may be possible to do things differently by having different Elm applications for each dynamic part within the page, though.

There is a future for Djelm and Proper server side rendering! But it is incredibly early days, so nothing to show for now :)

Oh cool. I believe this would really be the killer feature for Djelm !

[Confidenceman02]

It may be possible to do things differently by having different Elm applications for each dynamic part within the page, though.

You're exactly right, and this is exactly how Djelm works. Elm programs you create are actually reusable dynamic components for your server rendered UI, not SPA's.

You could actually make them SPA's however, but Djelm's core mission is to inject Elm programs into the parts of the static UI that needs reactivity. The video tutorial is a great example of that!

My opinions are that anything static should server rendered (Django templates), and anything dynamic should be Elm.

Of course if you want to do everything in Elm then that's ok to! Djelm will let you, but it's one step removed from what it really tries to be good at.

Oh cool. I believe this would really be the killer feature for Djelm !

I agree completely! It is a reach goal for sure.

[Confidenceman02]

Are you happy for this to be closed? Have I answered your original question with enough depth?

[YievCkim]

Yes of course we can.

I have still some interrogation but it's ok to close the issue.

If we have several Elm app do you see them completely isolated from the rest or is there a mean of communication between 2 dynamics parts ?

[Confidenceman02]

Interrogate away!

I just wanted to make sure we didn't drift too far away from the subject.

If we have several Elm app do you see them completely isolated from the rest or is there a mean of communication between 2 dynamics parts ?

It's like you are reading my mind for all the future Djelm features I want to build 😆

At the moment, yes, they can't communicate! However, I have absolutely thought about this.

Say you had server rendered page, but your Header is an elm program with dynamic stuff then your main content is all static, but at the bottom you have a fancy elm select type of program. Two different elm programs separated by static server rendered content, cool.

When you select things at the bottom of the page you want to reflect it in the Header, how do you do that?

Well currently you can't with Djelm BUT! You totally could with the right design pattern. The elm hydration code could be aware of the elm programs on the page, and it could dynamically update another program via a port. Becuase Djelm knows a lot about your programs, it could instrument a way for them to talk. That would be pretty sweet!

Again, future! 😄

[YievCkim]

I just wanted to make sure we didn't drift too far away from the subject.

If you want I can ping you on elm slack and continue the conversation here. Let me know.

[YievCkim]

You plan for the future looks really great. I hope you will see these things happen soon !

[Confidenceman02]

I just wanted to make sure we didn't drift too far away from the subject.

If you want I can ping you on elm slack and continue the conversation here. Let me know.

Oh great idea!

Im on there as Confidenceman02!