windflow-io / EternalEngine

Eternal Engine is an open-source cloud-based rapid application development platform for lovers of Vue.js and TailwindCSS.
MIT License
5 stars 1 forks source link

404 page missing #14

Closed sparkyspider closed 4 years ago

sparkyspider commented 4 years ago

When visiting https://localhost?host=hello the 404 "You can safely create a site here" is not displayed.

sparkyspider commented 4 years ago

Hi Markus,

Getting this right is going to be critical to getting windflow working lekker to create websites.

So @maoberlehner this 404 thing turns out to be a little bit more of an issue. We cannot create new pages if the 404 page doesn't work.

a) http://localhost:8080/?host=auth.windflow.local <- try and add a flow-link in this page. b) http://localhost:8080/new-page?host=auth.windflow.local <- try a create a new page here.

Then try and link (a) to link to (b) without losing the host.

maoberlehner commented 4 years ago

I'd like to build this in a way that there is no special path in the frontend code.

The way it is currently implemented, I have to catch 404 API requests, and create a new "empty" page on the client.

I think it would be better if the backend always returned just a regular page and the client is not concerned with any special logic.

So instead of sending

Status 404
{"httpStatus":404,"errorCode":"ERROR_003","errorTitle":"404 Domain Not Found","errorDescription":"No matching domain in the database","errorDetail":"ERROR_003: 404 Domain Not Found: domain: hello"}

send

Status 200
{
    "metaInfo": {
        "title": "Error",
        "htmlAttrs" : {
            "lang" : "en"
        },
        "bodyAttrs" : {
            "class" : "dark mode"
        },
        "meta": [
            {"charset" :  "utf-8"},
            {"name": "description", "content":  "this is the meta description of the about page"}
        ],
        "link": [
            {"rel":"icon" ,"type": "img/png", "href": "https://cdn.windflow.io/app/img/favicon-32x32.png", "sizes": "32x32"},
            {"rel":"icon" ,"type": "img/png", "href": "https://cdn.windflow.io/app/img/favicon-16x16.png", "sizes": "16x16"},
            {"rel":"stylesheet" ,"type": "text/css", "href": "https://cdn.windflow.io/app/vendor/tailwindcss/tailwind.min.css"}
        ]
    },
    "layout": "localhost.CenteredLayout",
    "areas": [
        {
            "area": "center",
            "components":[
                {"name":"localhost.ErrorSection", "id":"1"},
            ]
        }
    ],
    "data": {
        "components": {
            "1": {
                "errorDescription": "...",
                "errorDetail": "...",
                "errorTitle": "...",
            }
        }
    }
}
sparkyspider commented 4 years ago

I remember the reason we did this was to have a hard page in case stuff went pear shaped with the database so that we have a HARD (very reliable) page that can come up when the page controller is not working or there are issues with the component controller, etc.

I think this is important as a last line of defense else the user just gets a crappy broken page with no nice error page.

I think this is also nicer than the redirect to a hard failure page that we discussed.

Thanks,

sparkyspider commented 4 years ago

image

Implementing now... So when users edit a 404 page, we know what the namespace (siteid) that we need to use is.

maoberlehner commented 4 years ago

I remember that we talked about that, I don't remember the exact use case(s) we talked about. Anyway, I have a better idea about the overall frontend architecture now as I had then and I think the following setup would be most straightforward to implement on my end:

  1. User visits non existing page (404): server sends 404 for the HTML page, API sends 200 and JSON as above, frontend renders the page as usual, no extra logic required.
  2. User visits some page and there is some error (db down or whatever): server sends whatever 4xx or 5xx, API sends whatever 4xx or 5xx, frontend renders generic error page hardcoded in the code (no editing possible).
  3. User visits some page and for whatever reason the client throws an error while rendering or loading some component: redirect to error page.
sparkyspider commented 4 years ago

Actually, I agree! I will implement that. It also solves my github issue.

sparkyspider commented 4 years ago

I'm keeping this open until I've implemented this. Should be done tomorrow.

sparkyspider commented 4 years ago

@maoberlehner Done and committed.