Display a red pop up on error (routes)

Help me!
1

Hey folks :slight_smile:

I am currently having a behavior that seems a bit weird as I am sure it was working before…

In my route, I, most of the time, need to validate the input data on create/update and so, I am throwing error so the UI displays that red pop up on the bottom right with a text message that indicates an error

Exemple:

// Create a Item
router.post('/items', permissionMiddlewareCreator.create(), (request, response, next) => {
    // Learn what this route does here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/routes/default-routes#create-a-record
    throw new Error("Test for error pop-up")
}

Expected behavior

I would expect a pop up when Error are thrown from within a route

Actual behavior

Only some red output are displayed in the console

Failure Logs

Sometimes, I even get Unhandled rejection error (maybe related to a promise approach I have, i don’t know)

Context

Package json

{
  "name": "my-app",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node ./dist/server.js",
    "legacy-start": "node server.js",
    "build": "tsc",
    "start-dev": "tsc-watch --project ./tsconfig.json --noClear --onSuccess \"nodemon --watch ./dist ./dist/server.js\""
  },
  "dependencies": {
    "@types/express": "^4.17.11",
    "@types/forest-express-mongoose": "^6.3.3",
    "@types/mongoose": "^5.10.3",
    "axios": "^0.21.1",
    "body-parser": "1.19.0",
    "chalk": "~1.1.3",
    "cookie-parser": "1.4.4",
    "cors": "2.8.5",
    "debug": "~4.0.1",
    "dotenv": "~6.1.0",
    "express": "~4.17.1",
    "express-jwt": "5.3.1",
    "forest-express-mongoose": "^6.0.0",
    "mongoose": "~5.8.2",
    "morgan": "1.9.1",
    "nodemon": "^2.0.7",
    "require-all": "^3.0.0",
    "tsc-watch": "^4.2.9",
    "typescript": "^4.1.3"
  }
}

Thanks for any help!

Max

2

Hello @Emixam23,

Indeed with don’t have any kind you automatique error handling (middleware) on top of Express. So you can use a custom middleware or properly build the response for the client.

Becomes

response.status(400).send('Test for error pop-up')

I hope this will help you.
Morgan.

3

Hey there :slight_smile:

Thanks for your feedbacks but… I did find a bug :slight_smile: Based on your answer, I don’t know how/why, but I saw the light.

I let you test on your end, but I will provided you a model and 2 examples:

Item.ts

// This model was generated by Lumber. However, you remain in control of your models.
// Learn how here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/models/enrich-your-models
import {Document, model, Schema, Types} from 'mongoose';
import {INote, schema as note} from "./note";

export interface IItem extends Document {
    notes: [INote],
    title: string,
}

// This section contains the properties of your model, mapped to your collection's properties.
// Learn more here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/models/enrich-your-models#declaring-a-new-field-in-a-model
const schema = new Schema({
    'notes': [note],
    'title': String
}, {
    timestamps: false,
});

export default model<IItem>('items', schema, 'Items');

Of course, this model has a nested notes array, there is the definition:

Note.ts

import {Document, model, Schema} from 'mongoose';

export interface INote extends Document {
    name: string,
    content: string,
}

// This section contains the properties of your model, mapped to your collection's properties.
// Learn more here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/models/enrich-your-models#declaring-a-new-field-in-a-model
export const schema = new Schema({
    "name": String,
    "content": String,
}, {
    timestamps: false,
    _id: false
});

export default model<INote>('notes', schema)

Now that you have the model definition, I let you create one sample :slight_smile: Let say you create an Item “Test” that has a note with:

  • name: Foo
  • content: Bar

Now that you have everything setup, let’s create the “inconsistent” behavior (if I may call it like that).

BUG

Lets get to your routes/ directory and override the router.put(...) (so the update) section of your items:

// Update an Item
router.put('/items/:recordId', permissionMiddlewareCreator.update(), (request, response, next) => {
    // Learn what this route does here: https://docs.forestadmin.com/documentation/v/v6/reference-guide/routes/default-routes#update-a-record
    throw new Error("Hello there, let's throw an error!")
});

If you now update your previously created record’s title, you will see that red popup, no matter why. You can also use response.status(400).send("Hello there, let's throw an error!") and the result will quite be the same, this I agree with you.

However… now lets try to update our “notes” array :slight_smile:

If you update the existing “foo” note we have, it should run smoothly (note that I don’t get why I don’t get the error as it is an update…)

If you create a new note tho… that’s another story :sweat_smile: You do get the error displayed in the console, but nothing happens on the UI of ForestAdmin :confused: I should see the popup but I don’t see it

That’s kind of sad because, maybe I am missing something, which is a very possible option, either this part of forest admin is not very well done… I am saying so because, in this same section of the forest admin UI, I had this issue: Unable to update the layout for sub document definitions (mongodb) (related to another context, but to the same forest admin UI section/part)

However, thanks for your help/time, we really appreciate! I’ve been testing a couple of BackOffice solution but your is really good, keep moving forward!

Max

4

Hi @Emixam23,

Thanks for your detailed message.

You are right, there is a slight inconsistency between the creation and the edition of a sub-document:

  • the first one is using the PUT route of the main document (something like: /forest/items/609274d670cee3ffc9ca1d97)
  • the second one is using the PUT route of the relationship (something like forest/items/609274d670cee3ffc9ca1d97/relationships/notes/0).

I am creating a bug report on this so that we can homogenise this behaviour.

Meanwhile, can you tell me if / how this is blocking you achieving your goals? What is your usecase exactly?

Thanks again!