Unpoly2-rc9: broken multiple update targets / mainTarget and back button?

[Jo Voordeckers]

We're building a new app and chose to use v2-rc9 and are experiencing some strange behavior.

We've got 2 containers that always need to be updated on every page navigation, imagine a header and the body that are decoupled from eachother. 

We tried various approaches, either specifying up-target=".container, .header" on every link with 2 selectors, setting mainTargets=['.container', '.header'] or adding up-main on both containers. 

With up-target selectors it seems to work fine except the back button only updates the container matching the first selector. In the up-main or mainTargets case only the first matching target seems to get refreshed on forward/backward navigation. 

It seems quite common to update multiple sections on page navigation, what are we missing?

Thanks

- Jo

[Henning Koch]

Hi Jo,

> We've got 2 containers that always need to be updated on every page
> navigation, imagine a header and the body that are decoupled from
> eachother.
> We tried various approaches, either specifying up-target=".container,
> .header" on every link with 2 selectors, setting
> mainTargets=['.container', '.header']

The `up.fragment.mainTargets` setting is an array of alternatives.

With `mainTargets = ['.container', '.header']` Unpoly will first try to
match a `.container` element in both the current page and the server
response. If that does not exist it will fall back to matching `.header`.

Since you want to update both elements you should add them as a single
main target:

up.fragment.mainTargets = ['.container, .header'] // good
up.fragment.mainTargets = ['.container', '.header'] // bad

> or adding up-main on both containers.

Only the first `[up-main]` container in a layer is used.

If you want to go that route you should make your `.container` the
`[up-main]` element and give your header an `[up-hungry]` attribute.

Hungry elements are silently added to your target whenever they appear
in both current page and server response, but don't fail an update if
the server response does not match.

> With up-target selectors it seems to work fine except the back button

> only updates the container matching the first selector.In the up-main

> or mainTargets case only the first matching target seems to get
> refreshed on forward/backward navigation.

History changes update the main target. Because of the misunderstanding
explained above, this was configured to be only `.container`.

Best regards
Henning

[Jo Voordeckers]

On Sat, May 29, 2021 at 3:25 AM Henning Koch <hennin...@gmx.net> wrote:

If you want to go that route you should make your `.container` the
`[up-main]` element and give your header an `[up-hungry]` attribute.

Love it, it works now and is more elegant! 

Thx!

- Jo