Notification UI/UX

Is your feature request related to a problem? Please describe. The current state of Kepler doesn’t provide a standard way of displaying errors and it’s difficult for users to understand when something is not working the way it should be and for developers to extend UI in a cohesive and consistent way as part of the workflow.

Describe the solution you’d like If we consider Kepler.gl workflow we have the main steps:

• Pick source and load data.
• Create your visualization.
• Since Kepler.gl can also be consumed as library, the notification feature should be flexible enough to accommodate extensions/plugins.

Given the above use cases, Kepler.gl should provide flexible enough set of APIs to support multiple areas/topics out of the box, e.g. file/url/sharing and in more details – Ability to register new topics (maybe this is not needed, we can automatically detect the topic field from the notification entry) – Ability to register new notifications – Ability to remove notifications

Implementation This section will describe the implementation of the solution in details and will cover new APIs and their functionalities.

We can start form the the storage of the notifications The new feature should provide the ability to:

• Register notifications through API by calling a method, e.g. registerNotification, and providing the notification type, e.g. error, and which topic of the app the message is targeting hence we need to develop a little bit more on the second parameter and understand how this will be used to address the UI/UX. The register notification api will return the id of the newly generated entry
• Remove notifications: the user can call at any time the removeNotification and pass the notification id to remove the notification from the screen.

Storing solution We are going to take advantage of the uiState reducer and create a property object called notifications. Within the new notifications property we are going create an entry for each part of the application we want to target, e.g. file. The final result should look something like the following snippet:

const reducer = {
      uiState: {
        notifications: {
          file: [
            {
              uuid: 123456,
              type: 'warning',
              message: 'Your file contains invalid rows',
              topic: 'file'
            }
          ],
          url: [
            {
              uuid: 678901,
              type: 'success',
              message: 'Your url is has been loaded correctly',
              topic: 'url'
            }
          ],
          // this is generated by a consumer app
          sharing: [
            {
              uuid: 567890,
              type: 'error',
              message: 'The application is not able to upload the current map onto your dropbox account'
              topic: 'sharing'
            }
          ]
        }
      }
    };

Register a new notification Kepler.gl will provide a new API (action/helper) to register a new notification, the input of the new API will be an object representing the notification. In order to make the creation of new notifications we are going to provide helper methods The signature of said methods are the followings:

export type MessageType = 'info' | 'error' | 'warning' | 'success';
export type Notification = {
  uuiid: string,
  message: number,
  type: MessageType,
  topic: string
};
function createNotification({
      message: string,
      type: string,
      topic: string
    }): Notification {
      return {
        uuid: 'runtime generate and time uuid',
        message: 'whatever',
        type: 'warning',
        topic: 'file'
      };
    }

Describe alternatives you’ve considered A clear and concise description of any alternative solutions or features you’ve considered.

Additional context Add any other context or screenshots about the feature request here.

[heshan0131]

Agree with @macrigiuseppe and @btford on storing the errors/notifications in a central place: ui-state-reducer rather than spread them out to all places of the state.

Agree with @btford to use a flat array of notification instead of a map. each notification should have the same shape. then we can filter them based on type or uuid

type Notification should also be more flexible to allow user pass in additional payload if they need to. One of the common entry of error notification is the new Error object, which usually includes a handy stack trace.

[macrigiuseppe]

Agree with @macrigiuseppe and @btford on storing the errors/notifications in a central place: ui-state-reducer rather than spread them out to all places of the state.

Agree with @btford to use a flat array of notification instead of a map. each notification should have the same shape. then we can filter them based on type or uuid

type Notification should also be more flexible to allow user pass in additional payload if they need to. One of the common entry of error notification is the new Error object, which usually includes a handy stack trace.

Based on the conversation we are moving forward with the following requirements:

• Each error will have a type and uuid properties
• The array holding errors will be flat
• createNotification will allow users to pass extra optional properties