Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add raw mode #218

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

blindpirate
Copy link

Previous there is no support for complex dynamodb type (e.g. string set)
because JSON array is always interpreted as dynamodb list. This commit
adds a "raw" mode with which people can work with dynamodb type.

There's one more button "View Raw" in each row:

image

And a "Raw" checkbox in item page. You can click this box to switch between item mode and raw mode:

image

image

Add/Delete item is also supported:

image

Fixed #96

Previous there is no support for complex dynamodb type (e.g. string set)
because JSON array is always interpreted as dynamodb list. This commit
adds a "raw" mode with which people can work with dynamodb type.
Copy link
Collaborator

@rchl rchl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Can we remove the new endpoints and just handle different behavior using a query param?
  2. Can we get rid of the new View raw button and just remember the last state of the "raw" checkbox instead?

@@ -553,7 +555,7 @@ exports.createServer = (dynamodb, docClient) => {
})
}))

app.delete('/tables/:TableName/items/:key', asyncMiddleware((req, res) => {
app.delete('/tables/:TableName/*items/:key', asyncMiddleware((req, res) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In raw page, the delete requests are send as DELETE /tables/:TableName/raw-items/:key.

@blindpirate
Copy link
Author

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.

@rchl
Copy link
Collaborator

rchl commented Feb 21, 2022

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).

@blindpirate
Copy link
Author

blindpirate commented Feb 21, 2022

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!

@rchl
Copy link
Collaborator

rchl commented Feb 21, 2022

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.

@Hideman85
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants