Add mechanism for entering custom configurations in examples view.

[demiankatz]

I thought it would be useful to have a mechanism for providing custom configurations to the UV examples page in order to test configurable features (e.g. this came up because of a discussion about how to test #1061).

This PR adds a form element that can be used to input custom JSON configurations.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
universalviewer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 9, 2025 1:39pm

[LanieOkorodudu]

Thanks, @demiankatz. I hope I didn't complicate your work more.

[demiankatz]

Thanks, @demiankatz. I hope I didn't complicate your work more.

Not at all -- you just helped to inspire me to try to address a long-standing need. :-)

[demiankatz]

Here's an example that works --

By default, the "embed" feature is turned on in the share dialog. However, if you paste this into the config box and apply it:

{
    "modules": {
        "shareDialogue": {
            "options": {
                "embedEnabled": false
            }
        }
    }
}

...the embed option will be correctly hidden.

[demiankatz]

Here's a working configuration to disable pdf.js for testing:

{
    "modules": {
        "pdfCenterPanel": {
            "options": {
                "usePdfJs": false
            }
        }
    }
}

[demiankatz]

This appears to be working as expected now. The previous problem I reported seems to have been user error on my part, and not a problem with my configuration mechanism!

The only thing I don't fully understand is why I had to change the download dialog rendering code to account for an uninitialized state in order to prevent the config box from failing with a fatal error. I'm not sure if this is masking a deeper bug, or if this is just a reasonable thing to do.

[LanieOkorodudu]

@demiankatz, Thank you so much for adding the mechanism to enter custom configurations in the examples view! It’s a really helpful feature for testers, especially when we need to enable or disable specific icons during testing.

I just tried enabling the feedback icon using the following config, and it worked great, and thanks for providing the example.

{
"modules": {
"footerPanel": {
"options": {
"feedbackEnabled": true
}
}
}
}

[LanieOkorodudu]

@demiankatz, I've tested this custom configuration on my end, and it works as expected. As for the issue you're seeing with the download dialog rendering code, I don’t have enough context to weigh in on that. If it needs a deeper investigation and isn’t blocking the current work, it might be worth tracking in a separate issue. Just a suggestion, definitely not trying to complicate things. Really appreciate all the work you've put in. Thanks again!

[demiankatz]

Thanks, @LanieOkorodudu! I'm not sure whether the download dialog issue requires further investigation or not; perhaps we can discuss on today's stand-up!

[LanieOkorodudu]

@demiankatz, below is the screenshot of the 'feedbackEnabled' I notice that it works depends on the material. I have tested using PDF but if you test with the default example it doesn't work.

[rafeili]

We have bumped into some issues and have looked at these, so as a baseline the changes in PR 1062 are ok and can get merged.

[rafeili]

Okay to merge the PR.

[demiankatz]

The reason that @LanieOkorodudu's "feedback" example doesn't work consistently is that there are multiple footer panels that load in different contexts, and the same configuration needs to be applied to all of them to ensure that it is always active. Here's the config I had to use to get things working on my end:

{
	"modules": {
		"footerPanel": {
			"options": {
				"feedbackEnabled": true
			}
		},
		"searchFooterPanel": {
			"options": {
				"feedbackEnabled": true
			}
		},
		"mobileFooterPanel": {
			"options": {
				"feedbackEnabled": true
			}
		}
	}
}

This configuration behavior is confusing and challenging -- as I have suggested in the past, I think we need a more straightforward and potentially inheritance-based mechanism for managing configurations to avoid this kind of awkward redundancy. That's a task for a major release, though, so beyond the scope of the present sprint.

I will merge this PR now since the mechanism is working -- I will await follow-up work from @LlGC-mag to add additional functionality next week.

(@rafeili has also suggested adding a "reset" button to clear the config box and restore defaults -- if @LlGC-mag wants to add that while he's working on things, that would be great; if not, I'm happy to help as well. Just let me know what workflow is best!)