Open shilangyu opened 6 years ago
The reason primary
fragment exists in the first place is for the SEO (to generate a valid status code of the page) and not send 200/500 all the time to the client.
I am not sure how will you deal with status codes when two fragments have influence on the page, do you still mean to keep primary
and introduce the obligatory
attribute?
The way we deal with this problem is to have a fallback-src
attribute for the fragment, which can still render a usable page with most of the functionality.
do you still mean to keep
primary
and introduce theobligatory
attribute?
Yes.
The way we deal with this problem is to have a
fallback-src
attribute for the fragment, which can still render a usable page with most of the functionality.
Let's say the fallback-src
also fails. Tailor currently will ignore it, thats where obligatory
comes in, makes sure to raise an error so that we can act accordingly.
@shilangyu yeah got it, raise an error in the sense of returning 500 page?
500 sounds good, would the tailor.on('error', () => {})
be called after such error?
After having some thought process, I started to feel like this would mean we have to hold on to the response stream till all the obligatory fragments respond (normal src and also fallback-src) which will have a huge performance impact on time to first byte time.
Currently only a
primary
attribute makes a<fragment />
obligatory (if fails to load, creates an error). But it means we are limited to 1 obligatory<fragment />
per page.reason
Sometimes there are pages that need more than one microfrontend to work properly, therefore if any fails i'd like Tailor to create an error just like with not working
primary
fragment.proposition
maybe an
obligatory
attribute (shouldnt be a breaking change)if any of the two fails -> produce error