Skip to content
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.

Obligatory fragments #251

Open
shilangyu opened this issue Aug 24, 2018 · 5 comments
Open

Obligatory fragments #251

shilangyu opened this issue Aug 24, 2018 · 5 comments

Comments

@shilangyu
Copy link

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)

<fragment obligatory src="cart.microfrontends.io"></fragment>
<fragment obligatory src="products.microfrontends.io"></fragment>

if any of the two fails -> produce error

@vigneshshanmugam
Copy link
Collaborator

vigneshshanmugam commented Sep 9, 2018

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.

@shilangyu
Copy link
Author

do you still mean to keep primary and introduce the obligatory 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.

@vigneshshanmugam
Copy link
Collaborator

@shilangyu yeah got it, raise an error in the sense of returning 500 page?

@shilangyu
Copy link
Author

500 sounds good, would the tailor.on('error', () => {}) be called after such error?

@vigneshshanmugam
Copy link
Collaborator

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants