Can we remove the new endpoints and just handle different behavior using a query param?

I would personally prefer different way in url path instead of query param. I didn't see any other usage of query param, right?

Can we get rid of the new View raw button and just remember the last state of the "raw" checkbox instead?

That would introduce more complex states and where/how to save/retrieve/manage them. I'd like not to do so.

Query params are used for filtering/searching already.

I don't want to clutter the UI with another button that won't be that useful to most and also can be confusing. Since the "View item" page already has a toggle, that should be enough IMO.

And creating duplicate backend endpoints seems unnecessary really if the code handling both is basically the same.
Then we could also revert to previous code style (all logic contained within the handlers) rather than creating shared functions.
It's less code, less repetition and also the new queries would be backward compatible (minus supporting the raw presentation but still work).

Hi @rchl thanks for the opinion.

I'd like to share my use case, as that's the reason why I made this change and the UI design. In local development I need to update some DDB items frequently, i.e. "Open the item", "Update some value of it", "Save". The trouble was, there is a string set in my table which is displayed as JSON array, so previously, whatever change I made, that field was saved as list - open it, click save button, my local database broken. That's why I'd like it to be two buttons "View/View Raw": I know this item has a string set, I need to click "View Raw", "Update the value", "Save". If there is only one button, I need to click "View", "Change the checkbox", "Update the value", and "Save" - that's one more step. What's worse, once I forget to click the checkbox, my data was broken. Yes, I know the checkbox state can be saved locally in browser, but I really don't like keeping the state in an invisible place.

I'm happy to keep this change in my fork because right now I'm using it happily.

BTW, thanks for the awesome software, it helps me a lot!

But I don't see any problem with storing that state in a browser. That will most likely be still a convenient solution for you because if you are mostly or always editing in "raw" mode then it will be the default for you and you won't even have to think about which button to click.

I really want to avoid adding clutter and confusion to the UI. For an average user, he doesn't really know which button does what exactly and whether the current data requires the use of one over another.

I would love to see this feature available and published in the docker image 🙏 We also are having the same troubles with dynamodb sets that are not supported in JSON and therefore interpreted as list.

I kind of agree with rchl, in the end if we look the aws dynamodb console basically you click on the hash key, it open the item with the last config you selected, you can switch back and forth and save the item (then it becomes your latest layout preference). And so you dont have to worry about "Do I have a set in this table/item?" just click on the item and keep your view on raw mode.

Personally I'm almost always in raw mode in the console to avoid that issue.