Not re-rendering after value change

[charlesfries]

Possible duplicate of #18

There is a bug causing the breadcrumb helper to not recompute when its dependant data changes. It only seems to happen when the breadcrumb item is somewhere in the middle of the breadcrumb stack (i.e. the breadcrumb in question has an active subroute).

So far the only way I can reproduce reliably is to use debugger to force a timing delay.

Reproduction: https://github.com/charlesfries/ember-breadcrumb-trail/tree/timing

Steps to reproduce:

1. Clone and serve.
2. Visit http://localhost:4200/foo/bar with the inspector open and breakpoints enabled
3. Skip the breakpoints until there are none

Expectation

The "Home" breadcrumb should say "Home hello" after a delay of 2000ms.

Actual

The "Home" breadcrumb says "Home".

"ember-breadcrumb-trail": "^0.2.0",
"ember-cli": "~3.28.0",
"ember-source": "~3.28.0",

[Windvis]

@charlesfries Hey, thanks for the issue!

I took a quick look at the reproduction (thanks for that!) and it seems to be related to the value being updated while the breadcrumbs update loop isn't finished yet. This check fails, so the value isn't updated. It seems that it consistently works if you use run.later or next instead of setTimeout since by then the flag should be reset.

I'm not sure how this can be fixed in the addon though. That check is there to prevent infinite loops (since the addon forces a rerender) so removing it is not an option. I also don't see a way to tell the service that a specific update is fine. The only thing I can think of is adding some sort of diff checking to determine if the title and data has changed, but since the data object is fully user controlled that doesn't sound ideal either.

Can you provide more information about the real setup where you are running into issues?

All of these timing issues kind of confirm that using templates for things like this might not be the best solution (since it requires runloop hackery) and a "route based" breadcrumbs setup would skip all these issues, but the helper based API is so nice from a consumer point of view 😄. Ideally the helper would be an "effect", but that isn't a thing so I tried to mimic that behavior with the runloop. As you noticed, it's far from perfect 😄.