Toby

@Manoj Hotwire and Livewire are both great, but they are quite different approaches to building Laravel apps.

Hotwire is an approach to progressive enhancement. You are basically just building a traditional hypermedia Laravel Blade app with forms and links. Hotwire is a light sprinkle of JavaScript on top which enhances those forms and links to use AJAX rather than requiring a full page reload. The app will still work fine if JavaScript is disabled or fails to load.

Livewire, on the other hand, is a more fundamentally different approach. You use Livewire components which have proprietary paradigms for managing state and interactivity between the client and server. If JavaScript is disabled or fails to load, the app won't work.

Hotwire's approach makes a lot of sense to me, which is why I chose it for Waterhole. It's simple, light, resilient, performant, and has a great developer experience.

Hi @Michael, thanks very much for your kind words.

In my other job I work with both React and Vue, and coming back to Waterhole is always breath of fresh air. I find the Laravel + Hotwire stack much simpler to work with and reason about. There's no client-side state management to worry about, no rendering performance issues, and working directly with the models/database is refreshing.

I'm a huge fan of Laravel's Blade components in keeping the view layer nice and tidy. And I really like the Hotwire paradigm, because at the end of the day, it feels like I'm building a really basic web 1.0 app, just with a bit of progressive enhancement. I would highly recommend it!

Good question @riegel02!

default.js is bundled at runtime from a few separate JS files under vendor/waterhole/core/resources/dist - you might have more luck making changes in those files, but then they will still be overwritten whenever you update Waterhole, so this wouldn't be the recommended way to do it.

I don't think what ChatGPT has suggested will work, because the browser's request to cdn.jsdelivr.net will bypass your server completely.

In theory, the way to do this would be to add a custom script to monitor for <emoji-picker> elements and switch their data source to your own:

1. Create a new file at resources/js/emojiPicker.js:

function updateEmojiPickerDataSource() {
  document.querySelectorAll('emoji-picker').forEach((el) => {
    // https://github.com/nolanlawson/emoji-picker-element?tab=readme-ov-file#javascript-api
    el.dataSource = "DATA_SOURCE_URL";
  });
}

// Update emoji-picker elements already on the page
updateEmojiPickerDataSource();

// Observer for new emoji-picker elements added to the page
const observer = new MutationObserver(updateEmojiPickerDataSource);
observer.observe(document.documentElement, {
  childList: true,
  subtree: true,
});

2. Add it to your forum using the Script extender in app/Providers/WaterholeServiceProvider.php:

Extend\Script::add(resource_path('js/emojiPicker.js'));

However, unfortunately this is not actually working - I am still seeing requests to the cdn.jsdelivr.net domain when navigating between pages. I've run out of time to debug right now, but will keep thinking about how this can be achieved!

Is there any way we can add traits to the Waterhole\Models\User class in a similar way as adding relationships via the resolveRelationUsing method?

Unfortunately I don't think it's currently possible to add traits to the Waterhole User model. Again, I'll look into making the User model configurable so you can subclass it, but for now your options are to implement the desired relations manually using resolveRelationUsing, or use your own separate User model/table and then set up the Laravel authentication integration.

Also, regarding conditional rendering, the use of a closure doesn't seem to work with the Extend remove method as it only accepts a string param. Is this method going to be updated in the future to allow for mixed content instead of only strings?

Haven't tested, but try this:

$button = TextEditor::get('mention')['content'];
TextEditor::replace('mention', fn(string $id) => $condition ? $button($id) : null);

This is obviously quite a small community, but runs on a $14/mo DigitalOcean droplet with 1 premium vCPU and 2GB of memory. It would likely run well on a cheaper droplet, but I want things to feel very fast

I'd also be interested to hear how Waterhole scales up in terms of server resources!