Safely injecting the Eloquent record from an EditRecord page into both the rendered output and the preview of a Brick

[JolanUK]

Hi all!

I'm looking to implement a context to the Brick (or the Brick Collection, I don't mind) where I inject the current Eloquent record I've added the Brick to. It's a custom record edit page though: https://filamentphp.com/docs/5.x/resources/custom-pages.

The schema within the EditRecord:

public function form(Schema $schema): Schema
{
    return $schema
        ->components([
            Mason::make('content')
                ->bricks(TermCollection::make())
                ->doubleClickToEdit()
                ->previewLayout('components.layouts.mason-preview')
                ->extraInputAttributes(['style' => 'min-height: 30rem;'])
                ->displayActionsAsGrid()
                ->colorModeToggle()
                ->columnSpanFull(),
        ]);
}

The custom Brick:

<?php

namespace App\Mason;

use App\Mason\Enums\BackgroundColor;
use Awcodes\Mason\Brick;
use Filament\Actions\Action;
use Filament\Forms\Components\Radio;
use Filament\Support\Enums\Width;
use Filament\Support\Icons\Heroicon;
use Illuminate\Contracts\Support\Htmlable;
use Illuminate\Database\Eloquent\Model;
use Throwable;

class TermCourses extends Brick
{
    public static function getId(): string
    {
        return 'termCourses';
    }

    public static function getIcon(): string | Heroicon | Htmlable | null
    {
        return Heroicon::OutlinedCube;
    }

    public static function getLabel(): string
    {
        return parent::getLabel();
    }

    /**
     * @throws Throwable
     */
    public static function toHtml(array $config, ?array $data = null): ?string
    {
        return view('mason.term-courses', [
            'background_color' => $config['background_color'] ?? BackgroundColor::White->value,
            'config' => $config,
            'data' => $data,
        ])->render();
    }

    public static function configureBrickAction(Action $action): Action
    {
        return $action
            ->slideOver()
            ->modalWidth(Width::ThreeExtraLarge)
            ->fillForm(fn (array $arguments): array => [
                'background_color' => $arguments['config']['background_color'] ?? BackgroundColor::White->value,
            ])
            ->schema([
                Radio::make('background_color')
                    ->options(BackgroundColor::class)
                    ->inline()
                    ->inlineLabel(false),
            ]);
    }
}

Normally, I know I can create a custom field and pull in the record (https://filamentphp.com/docs/5.x/resources/custom-pages#using-a-resource-record) but I can't just pass in $this to the view. Using viewData hasn't worked either:

->viewData(fn(?Model $record): array => [
    'record' => $record
])

Any ideas? Thanks all!

[JolanUK]

There's a distinct possibility I've gotten caught up in nonsense. Is there a reason this should be handled in the Brick rather than as a super-simple prop in the view? I don't need to pass in the current Eloquent record until the view really, the only thing that's contextual for each user is already being handled by view policies.

@props([
    'record' => $this->term->courses,
])

[JolanUK]

I'm back to square one with this unfortunately. When adding a Brick with the above blade change, I have the same $this issue.

Using $this when not in object context

May be stumped here. toHtml needs to do the same thing regardless of the operation (preview or output into the frontend), do you have any ideas?

[awcodes]

Thanks for the detailed write-up — this turned out to be a real gap rather than you holding it wrong, and it's prompted a change on 3.x.

The short version

Brick::toHtml() has always had a second parameter:

public static function toHtml(array $config, ?array $data = null): ?string

...and nothing has ever passed anything to it. The renderer hard coded data: [], the iframe renderers
omitted it entirely. So the hook you were looking for existed in the signature but was dead. That's now
wired up.

What works now

Front end — pass the record as a third argument to the helper or the directive:

@mason($term->content, \App\Mason\TermCollection::make(), ['record' => $term])

{!! mason($term->content, \App\Mason\TermCollection::make(), ['record' => $term])->toHtml() !!}

Or on the renderer directly, which also takes a closure:

MasonRenderer::make($term->content)
    ->bricks(\App\Mason\TermCollection::make())
    ->data(['record' => $term]);

Infolists — MasonEntry supplies its own record automatically, no wiring at all:

MasonEntry::make('content')
    ->bricks(TermCollection::make())

...and ->data() overrides it if a brick needs something else.

In your brick, that lands where you were already looking for it:

public static function toHtml(array $config, ?array $data = null): ?string
{
    $record = $data['record'] ?? null;

    return view('mason.term-courses', [
        'background_color' => $config['background_color'] ?? BackgroundColor::White->value,
        'courses' => $record?->courses,
    ])->render();
}

The record key is just a convention — the array is yours, so if the brick wants the courses already
resolved, or a locale, or anything else, put that in instead.

Why your two attempts couldn't have worked

Worth spelling out, because both failures point at the same thing.

->viewData() sets data on the component's own view — Mason's editor wrapper (mason::mason). Brick
views are rendered somewhere else entirely, by Brick::toHtml(), so nothing you put there was ever going to
reach them.

The @props(['record' => $this->term->courses]) attempt hits the harder wall, and Using $this when not in object context is exactly the right error. Your brick's view isn't rendered inside your Livewire page. The
editor preview is a separate HTTP request: Mason's JS POSTs the blocks and brick list to
/mason/preview, and a plain stateless controller rebuilds the HTML from just that payload. There's no
Livewire component in that request, so there's no $this — and no record either.

Which brings us to the part I can't fully give you yet.

The preview

You put your finger on the real problem:

toHtml needs to do the same thing regardless of the operation (preview or output into the frontend)

Agreed in principle, and right now it doesn't. The front end and the infolist entry both feed the record
through; the editor preview still does not, so a record-dependent brick renders its $data === null
branch while you're editing. My advice for now is to write that branch deliberately — a placeholder saying
what will appear there reads much better than a brick that silently renders nothing mid-edit.

Getting the record across that boundary is genuinely easy — the entry already does it, and the preview route
could use the same mechanism in about five lines. What's stopping me isn't plumbing, it's that I don't yet
know what the preview should show:

1. Which record? In an edit form the Mason field sits next to your other inputs. If someone edits a
   title in a sibling field and hasn't saved, the preview would render the database row — so it'd confidently
   contradict the form two inches away. The infolist can't have this problem because nothing's being edited;
   the editor can, constantly.

2. There is no record on Create. getRecord() is null until the first save, so the preview would only
   ever be truthful on Edit. That's a half-feature, and a confusing one.

3. Cost. The preview re-renders on every state change — insert, edit, delete, move, undo, redo — with no
   debounce. Each becomes a POST. Feed it a record and every one of those re-resolves the model plus any
   relations the brick touches. Your $record->courses would be an extra query per brick per refresh. The
   entry pays that once per page view.

So the option I can ship cheaply is: the preview shows the last-saved record. Stale with respect to
unsaved sibling fields, empty on Create, and it costs a query per refresh — but for a lot of bricks (author,
publish date, related records — things you aren't editing in that same form) that's genuinely fine, and
it'd cover your TermCourses case since courses is a relation you're not editing in this form.

The alternative — the preview reflecting live, unsaved form state — is a different design: it means
rendering the preview through Livewire rather than the standalone route, or shipping form state along with
the payload and handing bricks something that isn't a plain Eloquent model. That's a much bigger change and
I don't want to commit to it on a hunch.

Since you're the one with the concrete use case: would last-saved-record be enough for what you're building,
or does your brick need to react to things being edited in the same form? That answer decides which way I
go.

[JolanUK]

Oh perfect, this is fantastic news. Funnily enough, I did try making a small incision into $data but I backed off after not being 100% confident I'd be overwriting something important (short of setting the key as something unreasonably unique I suppose).

So glad I could help improve the mechanism in my own way.

1. The guidance on viewData really helped, thank you. In hindsight it makes a lot of sense, there's no view directive in the Brick itself. Thanks so much for laying out the missing object context too, I'm happy to put that down as a gap in my knowledge but I'm going to take that forwards and learn from it (I frequently cause that error working in Filament).

2. Last-saved is a great solution. It's something I'm pretty happy with anyway because the relationship I'm pulling in (and subsequent policies) will make the end result completely different for virtually everyone anyway (content editors included). I think the preview alert box is just generally a really good standard to maintain anyway (even for other blocks), so I'm happy to work with that. I may fake in some example content on the preview anyway, just so the user can see roughly what it'll look like. I can then explain on the edit operation 'hey this isn't where you edit these though. You edit these things separately, over here'. It feels a much more sharply-defined boundary.

[awcodes]

Frontend stuff is released in 3.3.0.

I'll let you know about the preview. I'm still thinking through it all.

Thanks for the feedback.