Skip to main content

Release notes (August 29)

It's been a busy few weeks at Dromo HQ, and we've got some great improvements for you!

Validate the complete dataset before finishing

Sometimes, you may have the need to validate the full imported dataset before the user finishes. For example, you may need to check that a certain total number of rows were imported. Or you may need to check to see if any duplicates have been added to your database since the import was started.

The new beforeFinish callback enables you to do just that. It runs after the user clicks "Finish" and immediately before the onResults callback. The callback receives the full data and metadata in the same format as the results callback. You can perform any final validation on the data, and if there are issues that need to be resolved, you can return the user to the Review step with an error message.

Find more details in the docs!

React to changes in bulk

One of the most powerful tools in the Dromo arsenal is the row hook, enabling you to build custom transformation and validation logic that operates on full rows, and which fire both at the start of the import process, and any time the user makes any changes.

Dromo now offers a variation on the row hook. It works very similarly, except that instead of firing once for every row on initialization and once for every row after a change, it will only fire once on initialization and once per change action, regardless of the number of rows that have changed.

We call it the bulk row hook. Instead of receiving and returning a single record, it receives an returns an array of records, allowing you to react to changes in bulk.

For example, if a user pastes 50 rows into the uploader, the bulk row hook will fire once with the 50 rows.

You can find more about bulk row hooks here!

More control over the data you send to Dromo

Dromo's backendSync setting has been superseded by a new backendSyncMode setting, giving you more control over what you send to Dromo's secure backend.

The backendSyncMode setting has three options:

  • DISABLED is equivalent to backendSync: false. With this setting, none of your data is ever sent to Dromo.
  • FULL_DATA is equivalent to backendSync: true. This enables all of the features that our secure backend offers -- notably the import data API.
  • MAPPINGS_ONLY is a new option, and finds a happy medium between the two existing backendSync options. With this backend sync mode, only your field mappings (imported column headers to schema fields) are sent to and stored on Dromo's servers. This enables you to use the autoMapHeaders feature. However, the full import data is not sent to Dromo's servers, preserving any data privacy requirements you may have.

The nitty-gritty on the new backendSyncMode can be found here.

Read-only fields

You can now define fields as read-only by adding the readOnly: true parameter to the field spec. These fields will be visually distinguished in the Review screen, and will not be editable by the user.

Read-only fields are great when you want to populate a value exclusively using a row hook, and you don't want the user to be able to change that value directly.

Frontend license key domain restriction

The frontend license key is what you use in your frontend to load the Dromo Uploader. It is a publishable and potentially public-facing key.

Dromo now enables you to restrict the domains which may use your organization's keys. These domains will be the only ones allowed to load the Dromo Uploader, when not in development mode.

You can find this setting on the Organization page of the Dromo Dashboard.

Bugs squashed 🐛

  • When a user performs an import using manual input, there would sometimes be a jumpy user experience if the data was entered on any row except for the first. Now the import starts with only the row that the user entered data on, no matter what.
  • The cancel callback would sometimes fire after a successful import. The cancel callback now only fires when the user cancels.
  • If initialData was supplied, and the Dromo importer was closed and then reopened, the initialData would be lost. It is now preserved across multiple opens.