This looks awesome

[ksdme]

Hey,

Just wanted to say that this looks awesome. I have always tried to put together something like this every time I build something in Django. Gonna play with this over the weekend.

Do you have a discord server or something like that for the community?

Kilari Teja

[samwillis]

Hi Kilari!

Thanks ,I'm super excited for where Tetra could go. No discord yet, maybe one day when we've got a little further. For now GitHub discussions is perfect.

As you have spotted it's all quite early still. Looking forward to your feedback, and I'm sure you will find some bugs (just seen your pull request so then again you already have!). You will note that there isn't any tests in the repository yet, thats the next job on the to do list. I discovered it much better to get things out there sooner rather than delaying until everything is "done".

Let me know if you have any problems when trying stuff out, very happy to help!

[ksdme]

I agree about the tests, with something like this I think it's necessary to have something to get a feel for the developer UX.

I built https://github.com/ksdme/tetra-threads today to play around with the framework. You can access it at https://8000-ffbb1b16-3e63-4ba9-a59d-4544d414e739.tunnel.auditions.rehearse.sh/. There are some bugs which I couldn't address without making it look like a workaround. Maybe you can shed some light on the "tetra way" of fixing them. Here are a few:

1. How would programmatic navigation work? Once you create a thread, say you want to navigate away the user to the thread page, would fe js be responsible for building and navigating to the link once the public function is resolved? maybe a client callback? (I tried looking and couldn't find one).
2. When I navigate back to the home page after hitting submit on the create a thread page, the page is out of date and I need to refresh it to see the newly created thread. I suppose this could just be Chrome caching the page. Solving this probably directly relates to 1.
3. On a thread page, if I add a comment at the topmost level, I can only see it after refreshing the page. But, this isn't a problem when I add nested comments. This happens because I am trying to reuse the comment item component at the topmost level too (https://github.com/ksdme/tetra-threads/blob/main/threads/components.py#L70). So, when adding a comment the update only re-renders the comment item and not the whole thread component. This is fine for nested comments because the comment item itself is responsible for rendering the nested comments. This could be solved if there was a way to bubble events/messages upwards. A cursory research seems to suggest that LiveWire has something called listeners.
4. This is more of a question, is there a way for frontend js components to pass messages to each other without involving public fields? This sort of a mechanism would make building rather complex fe interactions possible.

I am bit confused about the scope of tetra too. Is it being designed to build most of the application using Tetra components or is this meant to be sprinkled around in the regular django applications?

Except for the things listed above, I am impressed by how fast this allows me to be once everything is setup and once I get into this frame of mind. I wish the VSCode extension supported intellisense and a cli to scaffold components would be nice too. One step at a time I guess.

Again, thanks for the awesome work!

[samwillis]

Hi Kilari,

Thanks so much for taking the time to give Tetra a go, I really appreciate it. As you have found not everything is there yet.

How would programmatic navigation work? Once you create a thread, say you want to navigate away the user to the thread page, would fe js be responsible for building and navigating to the link once the public function is resolved? maybe a client callback? (I tried looking and couldn't find one).

So there is a couple of things missing currently, first I haven't yet built a way to return a redirect from component public method. There are two options I'm considering, either returning a Redirect(url) object from the method, or using the callback queue such a self.client.redirect(url). I'm inclined to do the latter, the returned object from the public methods is available as a Promise when calling a public method from the browser, so that doesn't feel natural. Whereas the self.client.[method] api provides an explicit way to instruct the component to do something on the client from the server. Effectively redirect would be a thin wrapper of document.location.

The other thing missing is a router component, this would allow you to have Tetra do client side URL routing (it would obviously also run on the server). My intention is to reuse the Django urls system, but extend it to understand nested routes. That way you can have nested outlets in your templates, much like the Vue.js router I have most experience with.

When I navigate back to the home page after hitting submit on the create a thread page, the page is out of date and I need to refresh it to see the newly created thread. I suppose this could just be Chrome caching the page. Solving this probably directly relates to 1.

This is definitely a browser thing with the back button, I think its just loading the page back out of memory. If you manually change the url it doesn't happen so once we have a redirect method it won't happen. (I downloaded your code and ran it here so I could fiddle with it).

On a thread page, if I add a comment at the topmost level, I can only see it after refreshing the page. But, this isn't a problem when I add nested comments. This happens because I am trying to reuse the comment item component at the topmost level too (https://github.com/ksdme/tetra-threads/blob/main/threads/components.py#L70). So, when adding a comment the update only re-renders the comment item and not the whole thread component.

This also relates to your point 4 "components to pass messages to each other" too.

As you have spotted there is currently no way to instruct parent component to re-render. The plan is to expose a parent attribute/method on each component, we already have this internally (it's actually __parentComponent), and a render() method to instruct it to re-render. So from a component on the server you could call self.client.parent.render().

I also want to make Alpines $dispatch available via the self.client api so that you can use the DOM as an event bus passing a message up to a (great)grandparent component without having to know how far back up the tree it is.

For going to the other way, passing massages down to child components without having to do it via state I want to potentially use the Alpine.js. $refs. So you could set x-ref="something" on a component and then from the server `self.client.refs.something.method()'. A little less sure about that though.

(it's a pity that $ isn't an allowed charter in python variable names, all Alpine magics are prefixed with it and I would prefer these methods to be prefixed with it too)

Is it being designed to build most of the application using Tetra components or is this meant to be sprinkled around in the regular django applications

Eventually, once I have built a router, yes you could built a whole site/app with Tetra, but it's also meant to be possible to just "sprinkled around". I want to tackle both sides, easy to integrate into an existing Django app but also possible to use it to build something completely from scratch.

I am impressed by how fast this allows me to be once everything is setup and once I get into this frame of mind

Thanks, thats the plan. Obviously early days but I believe there is something good here.

I wish the VSCode extension supported intellisense

I would love that too! I looked into how to do it and it would require (from memory) extending the Python language server. It's not a small job but if Tetra becomes successful enough its definitely on the to do list.

What I realy want to do with the extension is make it do intellisense across the JS/Python boundary. So when typing self.client. you would get an autocomplete popup of all JS methods on the client and when editing JS you get autocomplete for server side Python methods. One day...

cli to scaffold components would be nice too

Yes, also planned.

Again thanks for taking the time to have a play with it and writing up some feedback. It all helps to steer where the priorities should be.

[samwillis]

Hey, so I have released a new version that fills a couple missing pieces from my to do list. You can now explicitly call methods of parent components and dispatch events to notify parent components of changes. Docs are here: https://www.tetraframework.com/docs/components#built-in-client-methods.

The simplest solution to your parent component not updating is to call self.client._parent._refresh(), alternatively you can "dispatch" a "new thread/comment" event and listen for that on the component that need to refresh (if you don't know how may parents up you need to call).

You can now redirect from a public method with self.client._redirect(url).

[ksdme]

Thanks, I'll try fixing those bugs with the new callbacks.

I have been trying to hack in a frontend event system into tetra that works more naturally with its component system. The end result should allow something like,

{% @ to_do_item todo=todo key=todo.id events: changed="closedTask($event)" / %}

The idea is for ToDoItem to be able to emit events at Alpine level which trigger JS in the ToDoList component Alpine scope. Because components have transparent bindings for server public methods, they could be used as event handlers as well. This model should make it easy to support bubbling events up without explicitly creating custom dispatch event names. Once we have something like this in place, we could support using it in reverse i.e. to allow child components to subscribe to events from parent component making it possible to have complete two way comunication, kind of how Angular does Input and Outputs.

The way I am trying to get this to work is by assigning a unique internal id for each component node which will be used while emitting (child components will know the parent component id and emit to it) and subscribing to events (parent component knows it's own id which will be used while subscribing). Note that when I say parent in this context, I don't necessarily mean the immediate parent of a component, but instead the effective event handler parent. Imagine, a component that uses another component with a block override, if you add an event handler to the content inside the block, those events should still be emitted and consumed by the outermost component.

At the moment, I am fighting with django template parser to establish the hirearchy and assign the unique identifiers. For a proof of concept, I might just ignore handling nested blocks which will make the whole process easier. I am yet to even start thinking about how morphing would handle these ids and resetting the event handlers.

Although, I am kind of worried that having this subsystem would make this framework a little more complicated for the end user. But it does enable much more flexibility and reusability while building components. One other solution I can think of is, distinguishing between Scope Inherited components and regular components. The ScopeInherited components would be components at tetra level, but not at Alpine level. At Alpine level they will just use the state/scope from the component that is embedding this component. Because parent component can interact with child components directly (via it's own state) this allows for slightly more reusable components but at the cost of muddying the parent state. So, yeah probably not a good solution.

Let me know what you think about this model.

[samwillis]

Thanks,

(Just spotted my link to the docs above was broken, fixed it)

Interesting idea with:

{% @ to_do_item todo=todo key=todo.id events: changed="closedTask($event)" / %}

I will have a think about how that would tie in, as you've noticed the Django template system can be a little difficult to work with. I had to do a bunch of work (and monkey patch it a little) to make it possible to trace where a {% block %} was defined so that we could exclude it from the saved state sent to the browser.

For events I want to see how people get on with the current implementation doing this:

@default.register
class MyComponent(Component):
    ...
    @public
    def my_method(self):
        self.client._dispatch('my-event', {"some_data": 123})

and subscribing with:

@default.register
class MyComponent(Component):
    ...
    @public
    def handle_my_event(self, event):
        ...

    template: django_html = """
    <div {% ... attrs %}
        @my-event="handle_my_event($event)"
        @my-event="handleMyEvent($event)"
    >
        ...
    </div>
    """

    script: javascript = """
    export default {
        handleMyEvent(event) {
            ...
        }
    }
    """

It keeps it close to the Alpine API (using the DOM as the event bus), and keeps the Tetra API small.

One option is to do something like this for listeners:

@default.register
class MyComponent(Component):
    ...
    @public.on("my-event")
    def handle_my_event(self, event):
        ...

But that results in just duplicating a lot of the Alpine API with all its modifiers, so I have left it off for now.

On events going the other way (to child components), I'm again a little unsure about it as it doesn't really match the DOM event model. It is however possible for a component to listen to events at the window/document level (https://alpinejs.dev/directives/on#window).

What I really want to do with child components is look into using $ref and x-ref (https://alpinejs.dev/directives/ref), which I think should be just a thin wrapper around the $refs magic.

[nerdoc]

Sorry, closed discussion accidentally. I'd like to keep that idea with $ref and x-ref, and opened a new discussion in "Ideas" for that.