Built-in store/restore position behavior can interfere with host apps

[rsimon]

I've recently started seeing JavaScript errors in Recogito Studio. The issue started when we added hash fragments to our URLs, to persist some UI state. Example:

SyntaxError: Failed to execute 'querySelector' on 'Document': '#rtab=open' is not a valid selector.

The error seems to originate from CETEIcean, specifically from this line: https://github.com/TEIC/CETEIcean/blob/c66d206e7a38f4f192bb0c2a5605e834112c516b/src/CETEI.js#L536

The line, I believe, is used here, to restore scroll position from a hash fragment that was previously set by CETEICean: https://github.com/TEIC/CETEIcean/blob/c66d206e7a38f4f192bb0c2a5605e834112c516b/tutorial_ja/js/CETEI.js#L858-L863

As a consequence, this now interferes with any "host application" that uses their own hash fragments.

Question: is this something we can opt-out from during CETEIcean initialization? If not, is this something we could make conditional in a future release? (I'm up for a PR if so!)

[raffazizzi]

Hello @rsimon you can opt out like this:

new CETEI({ ignoreFragmentId: true })

More info: https://github.com/TEIC/CETEIcean?tab=readme-ov-file#simple-usage-example

[rsimon]

Ah - sorry, I missed this. Works perfectly, thanks!

[raffazizzi]

No problem! FWIW I think it would be great to have this feature "opt-in" rather than opt-out, but we want to make sure some default behaviors that rely on it can work out of the box for more casual users.

[hcayless]

I'm a little torn about this. The reason the functionality is there is because CETEIcean may build out content after the page is loaded, meaning normal fragment identifier behavior wouldn't work as expected. What Rainer is doing is technically abusing the fragment id—which is a thing people may do with impunity :-). My own instinct is to make it fail more gracefully.

[rsimon]

Wait, what? Abuse!?! ;-)

Well... yes, I agree that the current setup does align with the way hash args are supposed to work. Opting out definitely works for us as an immediate solution. Also: if you have thoughts on how we could better encode UI state in the URL, I'd be interested. We had been discussing whether query args would be better. But then it seemed that this doesn't quite match either - because we're not filtering/selecting content, but instead control aspects that only concern the client view and are, essentially, ephemeral.

[raffazizzi]

Personally I don't see an issue in using query parameters to store some of the application state. Another option (if you have server logic) is to pass state values as part of the actual URL (like Google Maps does, for example with /data=). Or you can use localStorage or the IndexedDB API if sharing state via URL with others isn't a concern.

[rsimon]

API if sharing state via URL with others isn't a concern

I guess that's exactly our dilemma. In our case we do want to pre-set the view for others, as they open the link. (Which, in a way, might meant query params could make sense semantically? Even though they wouldn't have any meaning on the server side for us.) I couldn't really find a pattern that felt like the perfect fit.

[hcayless]

I agree with Raff. I wouldn't have a problem using query params here. Path params might be more technically correct, but they mean more config on the server side probably.