jetstream

[daemon-byte]

I plan to dig into why later but installing mary into a brand new jetstream disables all the forms. Has anyone already got this working or has some ideas that they can use to push me in the right direction?

[robsontenorio]

@daemon-byte have you tried Mary’s manual install steps?

[daemon-byte]

I only did the manual install and it breaks just by downloading the composer package. The yarn packages and adding daisy to the tailwind config doesn't break anything. But I didn't even have to add mary to it. Just doing composer require robsontenorio/mary was enough. It alters the template filling it with tags and turning the button to livewire and I suspect there's no matching component but that's just speculation at the moment. I plan to dig in further tonight when I have some free time. I'd like to get mary working with jetstream rather than just plain daisy

[robsontenorio]

As you describe the template have been modified, and that happens when you run php artisan mary:install. You can't run this command because it is supposed to be used on fresh install project.

I consider breeze/jetstream is not a fresh project, because it adds/modifies many files.

Give another shot:

• Delete de project
• Spin Laravel + Jetstram
• Then follow Mary's manual install.

[daemon-byte]

Oh I did. You can install a default jetstream and it works. Then run the commands

composer require robsontenorio/mary  
php artisan cache:clear  
php artisan view:clear  

And then the styling of the page will change (at least on dark mode) and it won't work anymore. Do a composer remove on the mary package, clear the caches and it will work again.

[daemon-byte]

It seems for whatever reason jetstream's using the x-form and x-button etc format and that's triggering mary.

https://github.com/laravel/jetstream/blob/4.x/stubs/livewire/resources/views/auth/login.blade.php

[robsontenorio]

Ok, now I got it.

Jetstream also has a <x-button> component, same as Mary.

Mary was designed to be the main component library. I am afraid if you want to use Jetstream you will need to handle this.

I will update docs to make it clear as possible.

[robsontenorio]

Docs updated with warning about conflits. If you know to solve this, please let me know and I will update docs again.

[Sophist-UK]

It seems to me that conflicts are going to become increasingly common as more Livewire component libraries are created and users want to pick and mix, and we probably want some better support for this.

Can we have components of e.g. "mary_button" and then register it also as "button" if an existing component called button isn't already registered?

[robsontenorio]

@Sophist-UK Even there is an option to prefix component names like x-mary-button, there will be conflict about css/js/settings in those starter kits.

Mary was designed to be the primary component source. If you want to keep Jetstream button you should rename it to something like x-jet-button

[Sophist-UK]

@robsontenorio Robson - The problem is that e.g. Filament might likely also take the same view that they should be the primary component source, whilst Jetstream might also take the same view, and clearly no more than one can be primary.

So (in an ideal world) it would be better if all component libraries followed the approach of having unique names as a primary name, and provide more common but more likely to be duplicated names as a secondary alias avoiding conflicts with prior loaded components with the same name (and relying on the order specified in configuration files which is under the users control to define which one gets primacy where there are clashes).

But regardless of the merits, from a practical perspective because Mary is relatively new and therefore has relatively few users (cf. e.g. Jetstream or Filament) it will be far easier for Mary to change its component names than other more established component frameworks.

The other problem with changing names in e.g. Filament or Jetstream is that such changes will likely require changes to the Filament or Jetstream source files, which would then create difficulties of reapplying changes every time they wanted to update to new versions.

Alternatively, how about providing a configuration prefix which defaults to the empty string, but users can e.g. set it to "mary-" and then use x-mary-button instead of x-button making resolution of conflicts as easy as adding the prefix.

That said, I do appreciate that having gone through early adoption and betas and delivered the first full release, changing tack now would be a significant issue (hence my suggestion for providing common names and backwards compatibility).

[robsontenorio]

@Sophist-UK Ok, I got it. On next release I will add a config file to make possible to set a prefix name for Mary components.

I will @ you when it is done.

[daemon-byte]

That'd be great because when forced to pick I went with jetstream/filament over this project. Replacing all that functionality vs manually including daisyui, particularly when tailwind is already configured. Wasn't a hard choice I'm afraid.

[robsontenorio]

@daemon-byte @Sophist-UK Just for sake of agreement , even with Mary prefixed components , you will need to handle yourself css leaking conflicts.

[Sophist-UK]

@robsontenorio I have no idea what that means? CSS leaking conflicts?????

[robsontenorio]

@Sophist-UK we can’t prevent things like #89

“… I'm using Breeze and also have some Filament tables elsewhere on the site … “

[Sophist-UK]

@robsontenorio Obviously you cannot fix issues with Filament components leaking all over yours - each project has to ensure that it is a good citizen and is not going to leak over other components if a user wants to use several LW3 component frameworks.

However, you might be able to coordinate a common approach with Filament & Jetstream whereby you agree to coexist and prevent leaks and possibly agree common tests to ensure that this is the case.