Suggestion for default values

[nicolagianelli]

When building reusable Blade components that utilize Bond for reactivity, we could face a synchronization issue between the initial server-side state (Blade) and the client-side state (Alpine).
​Currently, if we want a component (like a Button) to have a reactive variant prop, we have to:
​Declare the prop in Blade for initial server-side rendering (SSR) styling and redeclare it in the script tag.
​After this we have to manually check if x-variant exists in the $attributes bag; if not, we must manually inject it to ensure Alpine picks up the Blade prop as the starting reactive value.

@props(['variant' => 'primary'])

<script setup>
    mount((props: {
        variant: string,
    }) => ({
        init(){ ... }
    }))
</script>

<button
    {{ $attributes->merge(['class' => "...using $variant"]) }}
:class="{...using variant}"
>
</button>

Since the script is compiled, we cannot directly inject PHP into the JS. However, it would be beneficial to have a built-in way to declare initial values from PHP that Alpine automatically hydrates.
​The goal is to allow the Blade prop to handle the initial server-side styling while simultaneously informing the Alpine reactive state, without the developer having to manually sync the two in the attribute bag to set the initial x-variant prop.

We could avoid the server-side blade props but this will produce a flickering until Alpine starts and evaluate the classes.

A solution I tought could be to declare the initial values by using a blade directive like:
@jsProps(['variant' => $variant])
Or simple
@jsProps(['variant'])
And it will use the $variant value automatically.

Let me know if this makes sense or not.

[ganyicz]

Hey @nicolagianelli

Thanks for feedback!

This is interesting.

Can you share what is the actual thing you're trying to achieve with this?

I think I know where you're going but a more realistic and complete example would help me wrap my head around it.

In case of a simple button component with a variant, wouldn't you end up duplicating the classes between backend and frontend just to avoid the flicker?

Maybe we could find a better solution for that perhaps?

[nicolagianelli]

Hey @nicolagianelli

Thanks for feedback!

This is interesting.

Can you share what is the actual thing you're trying to achieve with this?

I think I know where you're going but a more realistic and complete example would help me wrap my head around it.

In case of a simple button component with a variant, wouldn't you end up duplicating the classes between backend and frontend just to avoid the flicker?

Maybe we could find a better solution for that perhaps?

In our use cases we needed the initial state only for UI/flickering purposes and, as you said, we declared the "dynamic" classes in a variable in php and directly used it in html and in alpine x-data via the @js() directive duplicating them.

I think the best way to handle these cases is to be able to sync the initial state in a simpler way but if you have other ideas maybe it could work.

In my experiments with Alpine and Blade components I would have loved to be able to declare blade props and let some of them be reactive and work like you did with Bond but if there is a simpler way to work and avoid SSR flickering I'm not going against it !

[nicolagianelli]

These are some basic examples @ganyicz

Initial value to avoid class/style flickering:

@props([
    'variant' => 'primary',
])

@php
    $baseClass = 'px-4 py-2 font-semibold rounded-lg shadow-md focus:outline-none focus:ring-2 focus:ring-offset-2';
    $variantClasses = [
        'primary' => 'bg-blue-500 text-white hover:bg-blue-700 focus:ring-blue-500',
        'secondary' => 'bg-gray-500 text-white hover:bg-gray-700 focus:ring-gray-500',
        'success' => 'bg-green-500 text-white hover:bg-green-700 focus:ring-green-500',
        'danger' => 'bg-red-500 text-white hover:bg-red-700 focus:ring-red-500',
    ];
    $class = $baseClass . ' ' . ($variantClasses[$variant] ?? $variantClasses['primary']);
@endphp

<button {{ $attributes->merge(['class' => $class]) }}
        :class="{
            '{{$variantClasses['primary']}}': variant === 'primary',
            '{{$variantClasses['secondary']}}': variant === 'secondary',
            '{{$variantClasses['success']}}': variant === 'success',
            '{{$variantClasses['danger']}}': variant === 'danger',
        }"
        x-data="{ variant: @js($variant) }"
        x-effect:variant="variant = Alpine.bound($el, 'x-variant', @js($primary))">

    {{ $slot }}
</button>

Initial value to avoid show flickering:

@props([
    'open' => false,
])

<div {{ $attributes }}
     x-data="{ isOpen: @js($open) }"
     x-effect:open="isOpen = Alpine.bound($el, 'x-open', @js($open))"
     x-show="isOpen" @if(!$open) x-cloak @endif>

    {{ $slot }}
</div>

With this method we can avoid flickering and when Alpine is initialized, the classes or show/hide variable becomes reactive by using the Alpine effect.

[ganyicz]

Hi @nicolagianelli,

thanks for sharing those examples.

I just implemented a new syntax for defining default values, this will be part of v1:

<script setup>
    mount((props: {
        size = 'lg',
        open: boolean = false, // with types
    }) => ({
        //...
    })) 
</script>

This doesn't solve the flickering by itself, but it's the first step (and this feature was needed anyway).

Now, the default values can be parsed on the backend so there's an opportunity to "prerender" something.

Also just to setup my expectations for this: I would like to avoid mixing JS with Blade inside Bond components. While it will be an option, in my head when you create a Bond component you're saying "this is primarily controlled by javascript on the frontend" so I'm trying to think of a "JS-first" solution.

But I'm definitely open to supporting some basic SSR-like functionality.

I can imagine something like a x-class directive that could be evaluated both on the backend and the frontend:

<div x-class=({
    base: 'bg-white rounded p-4',
    size: {
        sm: 'max-w-sm',
        md: 'max-w-md',
        lg: 'max-w-lg',
    },
    open: {
        true: 'block',
        false: 'hidden',
    }
})>

If the code inside x-class is just a plain object like the one above, we could evaluate this on the backend, take into account default values from mount and render out something like this:

<div class="bg-white rounded p-4 max-w-lg hidden" ...>

Once JS is loaded, it will take over and re-evaluate the classes with reactive variables.

If those end up being the same as the defaults there will be no flickering.

But this only solves the default values "from the inside".

In your code examples (eg. the modal) you have open as a Blade prop, but also x-open as Alpine prop.

What is the intention here? Would you then use the component like this:

<x-modal open="false" x-open="isModalOpen">

Knowing that isModalOpen is always false by default?

It would help if you also shared how would you use these components from the outside.

Thanks!