Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Style missing when using client:only directive #6931

Closed
1 task
timseverien opened this issue Apr 28, 2023 · 14 comments · Fixed by #7218
Closed
1 task

Style missing when using client:only directive #6931

timseverien opened this issue Apr 28, 2023 · 14 comments · Fixed by #7218
Assignees
Labels
- P4: important Violate documented behavior or significantly impacts performance (priority)

Comments

@timseverien
Copy link

timseverien commented Apr 28, 2023

What version of astro are you using?

2.3.2

Are you using an SSR adapter? If so, which one?

None

What package manager are you using?

npm

What operating system are you using?

Mac

What browser are you using?

Chrome

Describe the Bug

Summary

Given Svelte component with styles used in another Svelte component loaded with the client:only directive, styles of the inner component are missing on astro build.

Example

Let’s say we have a component called Flow to create vertical rhythm:

<div class="flow">
  <slot />
</div>

<style>
  .flow {
    display: flex;
    flex-direction: column;
    gap: 1em;
  }
</style>

Additionally, we have a component Card that uses Flow:

<script>
  import Flow from "./Flow.svelte";
</script>

<Flow>
  <div>Header</div>
  <div>Content</div>
  <div>Footer</div>
</Flow>

Let’s say we want to use the Card component client-side only. In index.astro, we write:

<Card client:only />

Everything looks fine, but on production the Flow style is missing.

Distilling the problem

  • The problem doesn’t occur on astro dev
  • The problem does occur when running astro build && astro preview
  • When the client:only directive is removed, the Flow styles are applied again
  • When the client:only directive is swapped for client:loaded or any of the other client:* directives, styles are applied again
  • When adding a <Flow> component to the index.astro, the styles are applied again, regardless whether we keep the client:only directive on Card or not

It appears astro build performs an action that astro dev doesn’t, which may discard styles or cause classname mismatches.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/bug-astro-svelte-styles?file=src/pages/error.astro

Participation

  • I am willing to submit a pull request for this issue.
@matthewp matthewp added - P4: important Violate documented behavior or significantly impacts performance (priority) - P3: minor bug An edge case that only affects very specific usage (priority) and removed - P4: important Violate documented behavior or significantly impacts performance (priority) labels Apr 28, 2023
@vampaz
Copy link

vampaz commented Apr 30, 2023

Can add that I've the same with Vue. I think it is related with this 7653cf9

@amxmln
Copy link

amxmln commented May 3, 2023

I can confirm this is an issue with Vue as well. Maybe it has to do with scoped styles?

Another thing I noticed, that may be of relevance is that the ordering of styles is different in dev and build. Importing normalize.css causes the styles from normalize to override my styles during dev, because it gets added after my styles, but everything is fine after build.

This started roughly around the same time the component styles disappeared when using client:only.

Edit: in case the style ordering isn’t related to this issue, I have opened a separate one here: #6975

@josephmcg
Copy link

I run into the same issue with Vue as well

@saxoncameron
Copy link

Any update on this one? Running Vue and have the same issue

@ironon
Copy link

ironon commented May 19, 2023

Same issue here with Vue. It's a really weird edge condition, as it used to work until it didn't. Changing the client directive didn't fix the problem in this case. Multiple nested vue components may also be causing a problem for me, as I'm unclear on how the client directives affect their children.

@tonyski
Copy link

tonyski commented May 23, 2023

same issue with Vue

1 similar comment
@TUBB
Copy link

TUBB commented May 26, 2023

same issue with Vue

@bluwy bluwy added - P4: important Violate documented behavior or significantly impacts performance (priority) and removed - P3: minor bug An edge case that only affects very specific usage (priority) labels May 26, 2023
@bluwy bluwy self-assigned this May 26, 2023
@bluwy
Copy link
Member

bluwy commented May 26, 2023

Sorry for the regression. I've looked into the issue and #7218 should fix it.

@Chudroy
Copy link

Chudroy commented Nov 10, 2023

Still got this problem with astro 2.10.15

@onurusluca
Copy link

onurusluca commented Nov 29, 2023

Still having the problem with Astro(also with Starlight), Vue and PrimeVue.

Edit: for anyone having the same issue, take a look at this template from PrimeVue repository. It works fine. The trick was to import needed styles in the components:
https://github.com/primefaces/primevue-examples/tree/main/astro-quickstart

import 'primevue/resources/primevue.min.css';
import 'primeicons/primeicons.css';
import "primevue/resources/themes/lara-light-indigo/theme.css";

@joechipjoechip
Copy link

Still have the issue with version 4.0.6 .. :/

@Fasa2509
Copy link

Same here but using Preact

@chowdud
Copy link

chowdud commented Jan 26, 2024

Getting the same with version 4.2.4 - specifically pertaining to loading in a stylised datatable, it momentarily renders in correctly, only then to have the styles removed completely.

@undead404
Copy link

This issue should probably not be closed. Got the same problem (styles, from an SCSS module, disappear after build but present in dev) with 4.2.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P4: important Violate documented behavior or significantly impacts performance (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.