-
Notifications
You must be signed in to change notification settings - Fork 133
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
base: master
Are you sure you want to change the base?
Add raw mode #218
Conversation
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.
56cec15
to
aca51b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Can we remove the new endpoints and just handle different behavior using a query param?
- 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) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
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
.
I would personally prefer different way in url path instead of query param. I didn't see any other usage of query param, right?
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. |
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. |
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:
And a "Raw" checkbox in item page. You can click this box to switch between item mode and raw mode:
Add/Delete item is also supported:
Fixed #96