Mjr Box Select Bundle Laravel Package

Getting Started

This is not a Laravel package. melk/mjr-box-select-bundle is a Symfony-style bundle whose only job is to register and ship Ext.ux.form.field.BoxSelect (a Sencha ExtJS "tag/multi-select" field) inside an MJR application. There is no service provider, no config/ file, no facade, no Blade directives. If your stack is Laravel-only, the honest answer is: don't install this bundle — vendor the ExtJS component directly (see below). Use the bundle only if you are maintaining an MJR/ExtJS admin panel alongside Laravel.

Minimal steps if you are in that situation:

1. composer require melk/mjr-box-select-bundle in the MJR app (not the Laravel app).
2. Register the bundle through MJR's bundle registration mechanism — not Laravel's bootstrap/providers.php. MJR predates the modern Symfony bundle autodiscovery conventions, so expect to add it to the app's bundle list manually.
3. Ensure the ExtJS framework itself is available — the bundle ships the ux component, not ExtJS. ExtJS is separately licensed and must be vendored or loaded from your Sencha build.
4. Where to look first: the bundle's Resources/public/js for the Ext.ux.form.field.BoxSelect source, the bundle's DI extension class for what it registers, and any view helper that exposes the boxselect xtype. That is roughly 90% of the package's surface area.
5. First use case: swap a combobox with multiSelect: true for a boxselect on a belongsToMany-style relationship — tags, categories, users-on-a-project.

{
    xtype: 'boxselect',
    name: 'tags[]',
    displayField: 'name',
    valueField: 'id',
    queryMode: 'remote',
    forceSelection: true,
    store: Ext.create('Ext.data.Store', {
        fields: ['id', 'name'],
        proxy: { type: 'ajax', url: '/api/tags', reader: 'json' }
    })
}

Implementation Patterns

Treat this as a front-end asset, not a backend integration. The bundle's day-to-day value is one JS class plus an xtype registration. Everything else — persistence, validation, search endpoints — is your application's work.

• Search endpoint (Laravel side): expose a small JSON route returning {id, name} pairs with a q/query param. ExtJS sends queryParam (default query) on remote stores, so map it explicitly rather than assuming q. Keep the response shape flat; BoxSelect's default reader expects an array or {data: [...]}.
• Write endpoint: the field posts an array of values. In Laravel validate with 'tags' => ['array'], 'tags.*' => ['integer', 'exists:tags,id'] and sync() on the pivot. Watch for the classic trailing-empty-string ("1,2,") when delimiter/forceSelection is misconfigured.
• Form config via Blade: since the bundle targets MJR views, in a mixed app emit the field config as JSON from Blade and Ext.create it in a Vite/asset entry. Don't try to make MJR's asset manager and Laravel's pipeline both own the same file.
• Store reuse: create one shared Ext.data.Store per entity type on the page and point multiple boxselects at it (store: 'Tags') — remote stores are the most common source of duplicate AJAX traffic.
• Initial values: for edit forms, pass values as an array of ids and set value after the store loads (store.on('load', ...) → field.setValue(ids)), otherwise forceSelection silently drops labels and you get raw ids rendered as tags.
• Pair with a displayTpl/listConfig override for anything beyond plain string labels; that is where you customise the tag rendering (colours, avatars, secondary text).

Gotchas and Tips

• Framework mismatch is the primary trap. Installing this into a Laravel app pulls Symfony-oriented dependencies that can conflict with Laravel's symfony/* constraints. If you only want the JS, git clone the repo and copy Resources/public/js into resources/js/vendor/ — that is the entire useful payload.
• Zero stars, zero dependents, zero maintenance. There will be no upstream fixes, no PHP 8.x/Symfony 6+ compatibility work, and no security response. Audit the JS before shipping it; fork it into your repo so the build can't break under you.
• ExtJS licensing is the real cost. ExtJS 4–6 is GPL-or-commercial. For most Laravel apps this requirement alone rules the component out. This package's score reflects the ecosystem, not the idea.
• The ux namespace must be loaded before any xtype is used. If you get Cannot create instance of unrecognized alias: widget.boxselect, it's a Sencha Cmd build ordering / requires problem, not a PHP problem. Add requires: ['Ext.ux.form.field.BoxSelect'] in your viewport class.
• Debugging tips: check the rendered <script> order in the page source first; then Ext.ClassManager.getByAlias('widget.boxselect') in the console. If it's undefined, stop looking at Laravel.
• Value/record mismatch: setValue with ids before the store loads throws no error — it just renders blank tags. Always bind to store.load or use addValue(record) explicitly.
• Extension points are all client-side: override onTypeAhead, createPicker, filterPickList, displayTpl, and listConfig. There is no PHP-side extension point worth mentioning.
• Recommendation for a Laravel developer: for a new build, use Tom Select or Select2 with a JSON search endpoint, or Livewire + wire:model for the multi-select — a fraction of the weight, MIT-licensed, and it composes with Laravel's validation and Eloquent sync() without an assets-management argument. Reach for boxselect only when you must match an existing ExtJS UI.