This document gives a short overview about steps needed to display/add/edit new redis data types introduced via redis server extension modules and so on.
Adding support for new types is most easy if redis command type
returns
a unique string and not on of the already supported datatypes (e.g. "stream").
For non unique types or types not directly know to redis (e.g. binary data has type "string").
there must be some kind of differentiation done server-side to toggle between
booth types.
This guide assumes Redis returns a new unique type.
- Add new EJS template inside
web/static/templates
folder to display data - Design new treeview icon inside folder
web/static/images
- modify file
web/static/scripts/redisCommander.js
the methodsgetIconForType()
and point to your own icon for the given new type. - modify file
web/static/scripts/redisCommander.js
the methodsloadKey()
, add another case to the `switch(keyData.type). The method called here should render the new template with given data. - modify
lib/routes/apiv1.js
methodgetKeyDetails()
and add handling of new datatype to switch expression. The new getDetails method must fetch all data displayed at the EJS template together with the TTL field. For unsupported commands in "ioredis" library theredisConnection.call('COMMAND', arguments)
syntax should be used. - Update README and CHANGELOG to mention new support.
The following steps add support to add new data for this type to Redis Commander. It does not allow modification of existing data.
- Update EJS template
web/views/modals/addKeyModal.ejs
, add new type to the "keyType" dropdown. If necessary add new Fields to the form that are hidden as default and only made visible whenever user selects this new type. The javascript code to handle form modifications on type selection can be found inweb/static/scripts/redisCommander.js
at methodsetupAddKeyButton()
. - Add server-side code to add new key data. On submit of the form inside the browser it calls
the browser method
addNewKey()
which in turn post the data to the server, triggering the methodsaveKey()
fromlib/routes/apiv1.js
. Add new data type to theswitch (type)
part here. - Add new "post", "put" routes to "apiv1.js" file for more explicit datatype support.
- Update README and CHANGELOG to mention new support.
Deleting data via right-click on tree or pressing "DEL" key is supported out-of-the box via
- Add delete button to the client-side EJS template that displays the data.
located under
web/static/templates
. This button should trigger thedeleteKey()
. - Make sure the client template only renders the button if not in read-only mode
(template variable
redisReadOnly
is not true) - To allow deletion via "delete" route add them to the "apiv1.js" file. This can be done together with the Modify data implementation.
- Update README and CHANGELOG to mention new support.
- Decide if data for this type can be edited directly (like string) or should be displayed only and
another modal dialog is needed to modify them., Update view template under
web/static/templates
accordingly. - Make sure to allow modification of data only if not in read-only mode
(template variable
redisReadOnly
is not true) - e.g. no "Save" button or loading edit modal when for read-only instances. - (optional) Add new modal to edit data, add EJS template at
web/views/modals
. Some more complex datatypes with "sub-data" (e.g. lists, sets, ...) use another modal ta add this new sub-data, e.g. add new data to a list and so on. These modals trigger their respective client-side javascript methods to check validity or post them to the correct server api. - Add extra methods to populate modals with data (similiar to
addXSetMember()
editXSetMember()
andremoveXSetMember()
inweb/static/scripts/redisCommander.js
). - (optional) add delete button to the modify entry modal. This button can either trigger an
explicit delete method server-side or (as most other do) set value to
tombstone
and send form to the update/modify method non server (similiar toremoveXSetMember()
inweb/static/scripts/redisCommander.js
) - Include all new modals at the end of the file
web/views/layout.ejs
beneath the other modals. - Add new "post" routes to "apiv1.js" file for more explicit datatype support.
- Update README and CHANGELOG to mention new support.