Completely new front-end & version 5.0.0!

[ildyria]

LOOKING FOR BETA-TESTERS & FEEDBACK !

Setup for testing

# Fetch the new branches, prune the non-existing ones.
git fetch -p

# Switch to the livewire branch
git checkout livewire

# Update the vendor files.
composer install 

# Update the database, there are new constants being used.
php artisan migrate 

# Set up the JS dependencies.
npm install

# Spawn the Vite server for hot reload pages on changes (recommended for development).
npm run dev
# or compile files (recommended for production).
npm run build

Then you can access the front-end at the following url:
https://yourlychee.example.org/livewire
Or by setting LIVEWIRE_ENABLED=false in your .env, in this case, the front-end will switch to Livewire completely.

Fixes

Fixes #12 — ✔️
Fixes #383 — ✔️
Fixes #725 — ✔️
Fixes #748 — ✔️ (need localization)
Fixes #828 — ✔️
Closes #845 — ✔️
Fixes #857 — ✔️
Fixes #1053 — ✔️ (no more public smart album)
Fixes #1211 — ✔️
Fixes #1249 — ✔️
Fixes #1189 — ✔️
Fixes #1253 — ✔️
Fixes #1462 — ✔️
Fixes #1676 — ✔️
Fixes #1704 — ✔️
Fixes #1720 — ✔️
Fixes #1732 — ✔️
Fixes #1744 — ✔️
Fixes #1825 — ✔️
Fixes #1891 — ✔️
Fixes #1948 — ✔️
Fixes #1973 — ✔️
Fixes #1989 — ✔️
Fixes LycheeOrg/Lychee-front#199 — ✔️
Fixes #2011 — ✔️
Fixes #2050 — ⚠️
Fixes #2051 — ✔️
Fixes #2058 — ✔️
Fixes #2068 — ✔️

Fixes LycheeOrg/Lychee-front#90 — ✔️
Fixes LycheeOrg/Lychee-front#104 — ✔️
Fixes LycheeOrg/Lychee-front#166 — ✔️
Fixes LycheeOrg/Lychee-front#268 — ✔️ (homebrewed css is gone)
Fixes LycheeOrg/Lychee-front#312 — ✔️ (already fixed actually)
Fixes LycheeOrg/Lychee-front#343 — ✔️
Fixes LycheeOrg/Lychee-front#344 — ✔️
Fixes LycheeOrg/Lychee-front#373 — ✔️

Major breaking differences

• Public smart album is gone.
• Making a single pictures public is no longer an option.
• Import from server is gone in favor of command line sync

From @qwerty287

Round 1

• Using the "back" button is extremely slow. It takes ~2 sec to load. Opening a new view (e.g. album) is fast though.
• The layout selector is also shown if there are no photos, I think it would better to hide it.
• Dialogs and right-click menus are still extremely slow.
• Navigating left/right on photos is extremely slow, it would be better to navigate directly and show a loading indicator.
• If you open/close the photo sidebar very often, at some point it does not work anymore and is always hidden.
• Opening the photo sidebar the first time moves the photo left first, then nothing happens for a short time, and then the sidebar opens. This should be synchronously.
• Not a big fan of the big buttons for photos, that gives me the feel this is software for children ;)
• When moving photos, the album list loads very long (it's pretty fast when moving albums though).
• Opening the album detail panel does not animate 100% fluently.
• Text inputs in dialogs have a weird border (e.g. login) Screenshot_20231003_123118

Overall it's working well (except the performance as I wrote above...), thanks for all the work!

Round 2

• When editing a picture and moving your mouse at the left margin, the half of the action icons appear (e.g. star, delete, turn)
• When editing a picture, I'd expect the "back" button to go back to the image view.
• Same as 2 from the album view: open the editor, go back to album view without saving, open a picture -> editor is opened.
• On empty albums, "Nothing to see here" is not horizontally centered.
• I can't open pictures from the map. On click, nothing happens.
• I can't use the "back" button to leave the map.
• Still, using dialogs and left-click menus is extremely slow for me and take about a second to appear.
• Opening the album details panel still hasn't a fully fluid animation.

[codecov]

Codecov Report

Attention: 280 lines in your changes are missing coverage. Please review.

Comparison is base (8019e1d) 84.07% compared to head (305215b) 85.67%.

Additional details and impacted files

[ildyria]

Dialogs and right-click menus are still extremely slow.

I will see what I can do to make this more reactive.

Navigating left/right on photos is extremely slow, it would be better to navigate directly and show a loading indicator.

That one is a tough one because the data are no longer just on the front-end.
This would pretty much require to re-implement the photo view to be part JS with the photo data stored in the album view.

What do you mean by navigate directly ? as in put a loading indicator while waiting for the next photo page to load ?

Not a big fan of the big buttons for photos, that gives me the feel this is software for children ;)

Well that can still be changed. :)

When moving photos, the album list loads very long (it's pretty fast when moving albums though).

That is pretty much the same as in the full JS front-end though. :/

Opening the album detail panel does not animate 100% fluently.

I am open to other idea of panels sliding or implementations of the visual. :)

[qwerty287]

What do you mean by navigate directly ? as in put a loading indicator while waiting for the next photo page to load ?

Yes, thats what I mean.

[qwerty287]

Opening the album detail panel does not animate 100% fluently.

I am open to other idea of panels sliding or implementations of the visual. :)

I don't mean a different animation, the concept is fine.
However, if you close the panel, it starts doing the animation, but it does not finish it properly: At some point, the panel is just hidden, but the animation did not hide it completely, so it looks a bit like a "jump". Something similar happens on opening.

[Fensterbank]

That one is a tough one because the data are no longer just on the front-end.
This would pretty much require to re-implement the photo view to be part JS with the photo data stored in the album view.

I did not yet test it, but based on the discussion I saw, it should behave like this:

• Keyboard navigation should indeed just be a JS thing, but the URL is changed and the photo url is changed. There is no need for this to be slow or loading a whole new page. So what we should avoid at all costs is doing something like onKeyPress={() => window.location = "mypage.net/livewire/3434234324" } which would result in a complete page load for ever image.
• To increase loading times of images, we could always preload the previous few and the next few images, which would result in no visible loading times. (e.g. instagram preloads around the next 6 posts, nobody wants to wait for the next image)

I have no clue about livewire, but I'm very experienced in JavaScript, so maybe (if my time allows it) I could take a look in some parts of the code and support in such cases.

[ildyria]

Hi @Fensterbank
Thank you for your inputs and you are more than welcome to look at the code.

Keyboard navigation should indeed just be a JS thing, but the URL is changed and the photo url is changed. There is no need for this to be slow or loading a whole new page. So what we should avoid at all costs is doing something like onKeyPress={() => window.location = "mypage.net/livewire/3434234324" } which would result in a complete page load for ever image.

In simplified, Livewire works a bit more like GitHub, meaning that it does an AJAX query to the server, which returns an HTML block and does in-place replacement on the page. We do not use window.location at all but more history.pushState(), allowing us to manipulate the url without reloading the full page.

The current version (4.13) is using pre-loading on the next and previous image, this is not fully an option (yet).
Currently the page change between pictures is indeed slower and that is something that is bothering me quite a bit. I am considering switching back to JS for the photo navigation (based on https://alpinejs.dev ) and keeping the Livewire components for the rest.

If you have 30 minutes to spare, this video is a good quick start on Livewire: https://www.youtube.com/watch?v=fX1aOWWt2nQ
It is the release of the v1, we are now using livewire v3 which is a full rewrite and has some change but is similar in the concept.

More docs on there: https://lycheeorg.github.io/docs/livewire.html

I believe that with combining Alpine, it should be possible to have vueJS-like experience on the Photo side while retaining the component part on the other pages.

To increase loading times of images, we could always preload the previous few and the next few images, which would result in no visible loading times. (e.g. instagram preloads around the next 6 posts, nobody wants to wait for the next image)

Switching to a vueJS-like experience on the photo view would most likely allow this. :)
More on a comparison between Vue and Alpine here

[ildyria]

Converting back to draft. Significant refactoring in the photo display for better usability.

[qwerty287]

Nice, and thanks for everything!
Some points I found:

1. When editing a picture and moving your mouse at the left margin, the half of the action icons appear (e.g. star, delete, turn)
2. When editing a picture, I'd expect the "back" button to go back to the image view.
3. Same as 2 from the album view: open the editor, go back to album view without saving, open a picture -> editor is opened.
4. On empty albums, "Nothing to see here" is not horizontally centered.
5. I can't open pictures from the map. On click, nothing happens.
6. I can't use the "back" button to leave the map.
7. Still, using dialogs and left-click menus is extremely slow for me and take about a second to appear.
8. Opening the album details panel still hasn't a fully fluid animation.

[qwerty287]

Most things are working as expected now, thanks!
However, something is very wrong with changing album covers. If I click the menu entry, an image is displayed fullscreen on the screen, but it's not necessarily the one I wanted to make the album cover. Also, the cover hasn't changed.

[ildyria]

You mean album header image ?

Yeah that one is not configurable yet. It is randomly selected on the landscape images in the current album (not considering sub albums).

See code here:

Lychee/app/Livewire/Components/Pages/Gallery/Album.php

Lines 154 to 175 in 2ed0a9a

	* Fetch the header url
	* TODO: Later this can be also a field from the album and if null we apply the rdm query.
	*
	* @return SizeVariant|null
	*
	* @throws QueryBuilderException
	* @throws RelationNotFoundException
	*/
	private function fetchHeaderUrl(): SizeVariant|null
	{
	if ($this->album->photos->isEmpty()) {
	return null;
	}
	return SizeVariant::query()
	->where('type', '=', SizeVariantType::MEDIUM)
	->whereBelongsTo($this->album->photos)
	->where('ratio', '>', 1)
	->inRandomOrder()
	->first();
	}

[ildyria]

However, something is very wrong with changing album covers.

Fixed, re-rendering was messing up with the display of images layout.

[tinohager]

Thanks for the great Christmas present :)

Is there already a docker container that I can test?
I think i have found the right one lycheeorg/lychee:nightly

[ildyria]

yeah but it is broken at the moment.

[tinohager]

i receive the following error after start

500
HttpException
Vite manifest not found, please execute npm run dev

[ildyria]

We are working on fixing that one. The problem is that npm is not run.

[ildyria]

@tinohager
To fix it temporarily you can add in your .env:

LIVEWIRE_ENABLED=false

[tinohager]

@ildyria if the sql root password is not correct the error message in the setup wizard might be a little more telling it sounds like lychee is not creating the database automatically instead of not being able to connect to the server

[ildyria]

Lychee is not creating the database no. But it will create the tables once given the database.

[tinohager]

@tinohager To fix it temporarily you can add in your .env:

LIVEWIRE_ENABLED=false

unfortunately does not work for me

[ildyria]

If you are using the docker compose, it should be in your lychee/conf/.env file.

[ildyria]

We are working on a fix for the vite part: LycheeOrg/Lychee-Docker#168 .

[tinohager]

will try again tomorrow to get it running, thank you very much and Merry Christmas

[ildyria]

@tinohager

lycheeorg/lychee:nightly

You will want to use temporarily lycheeorg/lychee:v5.0.0-beta before the build of tonight. Last nightly build is currently broken but lycheeorg/lychee:v5.0.0-beta is fine.