https://twill.io logo
Powered by
# ❓questions
  • p
    Hey! Yes, so from memory, repeater and block templates are handled early in the request, before controllers run, and maybe before view composers in some cases. That's why it's not possible to expose data from the controller to a block template.
  • a
    just adding a 
    script
    tag?
  • i
    @User 
    @php
    works, right? injecting a service within the block file with 
    @inject
    should too?
  • i
    well it all depends how you're building your js
  • i
    you can inline js in a block, but that's not really optimized
  • i
    usually you'd have a build process for your js and something in your block markup is helping with JS binding, like a data attribute
  • a
    maybe with 
    @stack
    - 
    @push
    directives
  • a
    ?
  • a
    and a 
    js/blocks
    folder
  • a
    It's the only thing that has come to my mind so far
  • i
    well, that's an approach for sure, but are you not compiling your javascript?
  • i
    if you can afford that, a stack is definitely a nice approach to only inline the js a page needs depending on which blocks are used
  • i
    but nowadays, you can also get that from a build, with dynamic chuncks
  • a
    im using laravel mix
  • a
    webpack for dummies
  • i
    this is how we structure our vanilla javascript (compiled with Laravel Mix as well): https://github.com/area17/a17-behaviors/wiki
  • i
    if we're not using Vue/React
  • i
    because this support dynamic and lazy behaviors, we don't need to define which block needs which js for optimization, the build will load the chunks it needs depending on the behaviors on the page
  • a
    I'll take a look, thanks!
  • p
    Yes, I tend to reach for 
    @php
    from the template. 
    @inject
    would be a nice improvement for the bread-and-butter cases like pulling stuff from a repository, etc.
  • p
  • k
    Just an idea, could be this be handled by Laravel macroables on 
    Response
    ? By appending new dynamic method on it which will resolve data for us?     Bad idea, cant call this in views. This needs to be invoked on controller level if so.
  • k
    But with 
    View
    macroable it works 😄
    Copy code
    php
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\View;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        
        View::macro('injectInBlock', function () {

            return 'dynamic data in block';

        });

    }
}
    Block preview file:
    Copy code
    php
{!! View::injectInBlock() !!}
    Result
  • k
    But it is much easier like u said earlier before with 
    composer
    .
  • p
    Nice one @User! Not sure I would use this to access simple data but macros are super powerful. In this example, thinking of it like a "view method" but declared from 
    AppServiceProvider
    , could provide access to other useful private methods from the same context.
  • h
    Copy code
    php
<?php

namespace App\Twill\Block;

use A17\Twill\Services\Blocks\Block;

class TextBlock extends Block
{
    public function getFormData(): array
    {
        return ['test' => self::class];
    }
}
  • h
    This will only be loaded once for an editor which is normal
  • h
    Also adding
  • i
    great stuff @Harings Rob !
  • u
    Hi, sorry for troubling but is there any docs that contain list of all Twill Vue components that can be used inside the Custom CMS Page or all of it already listed in here : https://twill.io/docs/custom-cms-pages/#example ?
1...266267268...484Latest