Changes

• Update width for body to avoid horizontal scroll
• Fixes Issue #209

Testing

Tested if page scrolled horizontally on chromium-based browser and Firefox.

Docs

N/A

fyi I ran into some trouble debugging a collection that changed the permalink to not match the file name here: #483

0.12.10 is an old version still.

@ewatch would love your help on this!

This would mean markdown need to respect the format YEAR-MONTH-DAY-title.md to be not treated as drafts

Not sure I follow, why wouldn't this work with a title.md file?

After seeing the new Next.js Script component, what it can do, and the positive developer response to it, I'm now in favor of solving this that way.

• We don't touch any <script> elements in your astro template, and ship directly to the browser
• We add a Script component that can do all of these features that we'd like (ex: control load order, dedupe, minify/bundle or leave alone, etc.)

One reason I'm anti .astro.md is that I'm worried about what happens when React lands .server.js and .client.js server components, would having .astro.md feel strange then? Maybe that's an overreaction though! If everyone else likes it, then I'm definitely not blocking it :)

Thought about this a bit more, and I think we should stick to HTML syntax over React or Vue syntax. Reason being, that you're in an Astro component and Astro syntax is a superset of HTML. Using framework specific sugar would break this guarantee.

That would mean converting things like className & htmlFor in the React renderer. To be honest, I bet we could disallow setting the style prop on React components for now. But if that's a dealbreaker, we could convert that to an object for you automatically as well.

tbh #497 is plenty for where we are at right now. Anything more I think would require the ability to really parse your CSS, which I know @drwpow had mentioned wanting to avoid for now.

A reminder for anyone concerned about perf: a reused classname gzips REALLY well. This probably has less affect on loading perf than you'd think, especially once #497 is merged.

also @tony-navillus in the example repo:

• I think you meant to do import Layout from '../layouts/Base.astro'; in $authors.astro
• $author set the permalink /authors/ which was really tricky to debug. Comment for @snowpackjs/maintainers : I think we need to prevent permalinks from escaping their name and save users from this footgun ($foo.astro should only be able to create /foo/* permalinks).

Oh, this is a bug: Collections data() currently needs to return an array. If you make this change, it appears to work:

        async data ({ params }) {
            console.log('data() params: ', params);
-            return allAuthors[params.index];
+            return [allAuthors[params.index]];
+             // then, grab from `collection.data[0]` in your template
        },

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/pikapkg/astro-www/9UnZqoGk2Ga5KvM1wC5Rt5cU38vv
✅ Preview: In Progress

⚠️ No Changeset found

Latest commit: 857475004a921f52ba5644dba4fb94a59135d8c7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

<details><summary>This PR includes no changesets</summary>

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

</details>

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Changes

• Update width for body to avoid horizontal scroll
• Fixes Issue #209

Testing

Tested if page scrolled horizontally on chromium-based browser and Firefox.

Docs

N/A

cc @drwpow

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/pikapkg/astro-www/2cQ4925fE81c2deKaUNGLGcXxVce
✅ Preview: https://astro-www-git-perf-optimize-scoped-class-pikapkg.vercel.app

⚠️ No Changeset found

Latest commit: c1852fa885929e0e2773cc0edb6c0b8558d1a537

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

<details><summary>This PR includes no changesets</summary>

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

</details>

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Changes

This is a partial solution for #472. Instead of injecting the astro-* class into every Astro component, this only injects it for components that use <style>.

Testing

Added a test in astro-styles-ssr. Maybe not the best place? It seemed like the most relevant area.

Docs

Nope, optimization only.

Had a chance to do some debugging on this one. I haven't totally nailed down the issue, but it may end up being a misuse of the collections API

What I'm attempting to build is:

• src/pages/$authors.astro page that compiles to /authors/index.html or similar. This page will act as an index listing each author found after scrubbing each blog post
• src/pages/$author.astro which compiles to an individual page along the lines of /authors/author-one/index.html. Each page will be a filtered list of post previews written by that author

Best I can tell, runtime.ts is assuming that the $author.astro component is can be called for routes /author as well as /author/author-one. I'm hitting an error because runtime tries to call data({ params }) with the params for a /author route, but that route shouldn't exist and doesn't get any data.

It looks like the runtime logic is mixing the use case of pagination and individual pages per item, but I haven't had a chance yet to find the best way to untangle the two.

Ran out of time for the night but hopefully this is useful in case anyone picks up this bug before I get back to it!

One straight-forward optimization here would be to not apply the astro-xxxxx class if the component has not <style> block. But I definitely agree that we could try to purge the classes as a final build optimization.

Haha, whoops! This is a bug but also worth discussing if we should fix it in relation to #495.

Very on the fence about this one! It would be nice for astro files to be more consistent, but it's obviously a lot less confusing and error-prone to just pass exactly the format your component needs.

That being said, there's a very clear place where renderers could modify props before passing them to the framework component. So this is more of a question of if we want implicit behavior.

In general, how should Astro handle syntax that is specific to a particular framework? For frameworks that have HTML-specific syntax (like Vue), I think we should encourage the use of that. For JSX-like languages, should we just require users to be explicit?

React

• Use className
• Use htmlFor
• Use style object

Vue

• No :prop, use v-bind:prop
• No @event, use v-on:event

Just an opinionated note that progressive image loading might be considered a complete anti-pattern from UX/communications perspective.

Progressive image loading usually ends up being page-render-time animation that leaves users attention focused on the images themselves after the rendering. 99/100 you just don't want that. You want users to focus on most important element of the page, call to action or so.

I think just need a 'feature' to brag about, that's why they enable this by default without putting much thought on the actual outcomes.

My proposal is to keep any framework-defined image loading completely opt-in, not something to enable by default.