Toby

No ETA, but can confirm that the JSON API implementation is mostly complete (it will be read-only for now), as well as the changes to the extension API. It's not a particularly exciting release, but it's coming!

In general, yes, it's wise to add a package you explicitly depend on to your project's composer.json file, rather than assuming that it is included via one of your other dependencies. This way you can specify your own version constraint, and then if there is an incompatibility between the version you depend on and the version Waterhole depends on, Composer will yell at you.

If you want to depend on a version of the package that Waterhole is not compatible with, then you would need to either wait for Waterhole to update or separate Waterhole into its own project.

@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!