Toby

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!

Hi @René, thanks for checking in! Absolutely, I'm disappointed that I haven't been able to get the next release out the door yet. I think a combination of life being busy and the changes slated being relatively large/overwhelming has made it hard to find the chunks of time needed. I appreciate the nudge and am going to make a more concerted effort over the next month - stay tuned.