Shape the Future of AstroWind 2.0: Your Feedback is Key to make AstroWind better!

[prototypa]

🚀 Greetings, AstroWind Community! 🌟

We hope you're having a fantastic day! We're excited to share that we're taking the first steps in developing AstroWind 2.0, and your contributions will be key in shaping the AstroWind 2.0 Roadmap. 🎉

Your voice matters! Our goal is to make AstroWind one of the most useful free templates for developers. Your feedback and suggestions are vital in helping us achieve this vision.

Do you have a feature you're excited about or an improvement to suggest? We're all ears! Your insights will be instrumental in our mission to make AstroWind incredibly useful for developers everywhere.

We appreciate your time and your valuable insights in advance! Together, we'll make AstroWind even more amazing. 💪

[houseofsails]

I'm very new to astro in general, but I have spent the past few days familiarising myself with the framework. I absolute love the look of this theme - and the structure makes building websites a breeze.

However, if I had to add anything (coming from a junior developer level experience level) I'd say the ability to easily create widgets and add these to custom homepage layouts is a must.

At the moment I need to create multiple files and edit the blog.ts, along with other core files, to create includes for the homepage - and even then I'm not sure if I'm doing it correctly. Some things seem to work, while others won't render at all.

I appreciate all the work you have put into this already, and I know creating custom modules is a ton of work, but having some way to make this possible for people to do themselves would be a huge win in my opinion.

So a simple system to be able to create custom widgets and such would be my first suggestion, if it's in any way possible to do that.

Other than this, I'm looking forward to seeing which direction you take things in next!

[tomByrer]

easily create widgets and add these to custom homepage layouts is a must

IMHO Astro is already fairly easy to create custom components. Though I an AstroWind2 specific tutorial & examples would be a great idea.

[0xDeadcell]

I'd love to see some shortcode features built in, like how this hugo theme has:

https://willfaught.com/paige/shortcodes/

[tomByrer]

No; that's what MDX is for.

[widgeter]

Full support for all current Astro options for ouput: 'static' | 'server' | 'hybrid'

The current version of AstroWind only works with 'static' and 'hybrid'. Supporting SSR has been a frequent request in Discussions and Issues:

• Great template, but limitations with SSR and dynamic content handling #346
• Blog fails when SSR is enabled #194
• About Node Adapter #188
• Vercel Adapter Error. #260
• Blog fails when SSR is enabled #192
• HTTP ERROR 500 when deploying astrowind project #31

cc: @codewithdary, @jussi-photografi, @bencipher, @directormac, @AndresBarretoDev, @SamuelAierizer

[AlexRMuc]

Thank you for the opportunity to contribute to AstroWind 2.0! I am eager to share some ideas that I believe could significantly enhance its utility and appeal for developers. Here are my suggestions:

• Internationalization with Language Switch Button: Incorporating internationalization features with an easy-to-use language switch button would make AstroWind more accessible to a global audience.
• Drop-down Mega Menu: Adding a drop-down mega menu would significantly improve navigation and user experience, especially for sites with extensive content.
• Table Widgets: Inspired by the advanced tables seen on Flowbite, integrating similar table widgets into AstroWind could greatly enhance data presentation. These tables could include features such as sorting, filtering, and pagination.
• Form Widget: Introducing a form widget with validation capabilities would be highly beneficial.

[dvriv]

Support for CMS would be really good. But there are too many CMS and would be impossible to support all of them so would have to choose a few of them that work well with Astro.

I would vote for Sanity :)

[EternalX267]

I don't know how different CMSes compare, but one that I saw that looked like a nice, easy to use one is Pages CMS. It just needs a config file setup to describe how different content is organized, which shoul be consistent for a template.

Another fun one I saw was editable.website which does live updating.

Pages CMS look's amazing!

[tomByrer]

Maybe just abstract the CMS layer into something like an ORM, & have adaptors for different CMSes?

[prototypa]

Yes @tomByrer, that is why we have an extra layer above the Contents Collection. Every time we need to do a project internally we make adjustments to that layer. However, bringing that to the CMS level involves several complexities that we are reviewing. One is that Astro can render the same in static mode as server, and the way to handle this varies a little according to the situation. The other is that not all existing CMSs simply return data, some are responsible for rendering components, etc.

We are working on cleaning up what we have so far (which also has unnecessary code since it was created before many current Astro features existed), and creating at least some useful and type-varying adapters for an ORM layer.

Thanks

[jakehartigan]

Was going to manually add Decap CMS today and found that it was already started (as mentioned earlier). I was very grateful as I was bound to at least have a typo. If a more robust CMS integration is possible that would be awesome.

[faneye]

I suggest to use directus.io, the possibilities are unlimited.

[Ndrewndrew]

Astro db integration!

Auth maybe?

[AdamGEmerson]

I would love to see the landing page templates finished out. Currently there are links for them, but no content (just a hero section).

[zipziz]

In an effort to enhance the accommodation of CJK (Chinese, Japanese, Korean) characters, thereby meeting the specific requirements of users from these linguistic backgrounds, the following suggestions have been proposed for AstroWind 2.0:

1. URL and Front-end Display Compatibility: Ensure that URLs are CJK friendly, aiding in a more intuitive and seamless navigation experience. This is especially pertinent to the concerns raised in issue #397, which highlights the importance of making the front-end display more accommodating to CJK characters.

2. Font Compatibility: It is recommended to optimize for font compatibility by favoring the use of default system fonts available on the user's device. This approach not only ensures a more uniform appearance across different platforms but also significantly improves load times and enhances the overall user experience by adhering to the native look and feel of each user's device.

These enhancements are believed to significantly contribute to making AstroWind 2.0 more user-friendly for developers working with CJK languages, thereby broadening its appeal and usability across a more diverse audience.

[prototypa]

Hi @zipziz

What do you mean in point 2 about Font Compatibility?

The Template comes with a default font but you can use any font you want or even leave it blank.

Maybe it is important to work on the documentation, there are questions that have answers but do not depend on a change in the code of the current template.

In all ways, if you can explain more to us on point 2, it would be helpful for us to know how to handle the situation.

[prototypa]

Hi @zipziz

1. We have fixed issue 1 with: f234e63

2. Regarding point 2, you can go to src/components/CustomStyles.astro and install or reference from some online font service (like Google Fonts) the font you want. You can also not use any font and define system fonts in the css variables.

Let us know if it works like this for you.
Thank you

[RelativeSure]

My issue is that Google is already integrated. It was the thing that made me not want to use this theme.
I really really like how it looks but in my book there's also too many example pages to cleanup and remove.
My worry is how google can track a website visitor. Do I have to create banner, privacy and gdpr stuff aswell just because of Google's integration?

It would love to use this if it wasn't integrated per default. Maybe create another astrowind theme that's more scraped and doesn't have so many integrations and pages?

[RelativeSure]

Thanks for the quick reply.
I mean that Google analytics is built in which is sadly a huge no go for me.

Personally I'm actively trying to use things that doesn't have anything to do with Google and/or Meta/FB.

[prototypa]

Oh I understand. You try not to use anything that includes Google or FB.

In the case of AstroWind, analytics is disabled by default, so if you don't activate it, nothing happens.

It has also been useful for us to know that. Thank you, we will take that into account.

[djfdat]

Having different analytics providers that we can choose instead would also be great!

[jakehartigan]

Personally, I really appreciated how easy it was to integrate Google Analytics with a few edits. It would be ideal if it could stay just as easy while accommodating others. Maybe offering more modular ways to customize the template would be a good solution.

[djfdat]

Plausible and Umami are the two big ones I know about that are more privacy-focused.

[prototypa]

Ability to update the template and generate code on demand.

We and the community often use the template to start new projects. The template gives the advantage of starting from a solid code that includes SEO, performance, dark mode, well structured, clean design, etc. etc.

However, sometimes it is difficult to update a project already started based on the template when there are new important updates to the template. Also sometimes it is necessary to delete a lot of things from the template to adapt it to our needs.

For this reason in the AstroWind 2.0 version we propose:

• Make the template updatable
• Start from different seeds (ex: empty, portfolio, blog, landing page, full...)
• Allow installing Widgets on demand and updating them.

But, and how? Initial review:

• The template will have an astro astrowind-integration dependency that will include everything that is basically code base that supports fundamental functions and barely needs to be changed. For example, permalink utilities, image utilities, blog utilities, our Image component, optimization tasks,...
  • To update all that base code, you would only need to update the integration.
• There will be a terminal command package to install templates from different seeds and manage Widgets and Components (add or update). These variations of AstroWind will live in a repository and each one will also have its demo. They may be updated by the community.
• There will be a public repository with all the Widgets and Components that we use in AstroWind. This way anyone who detects a problem in a widget or component can collaborate and correct it.
• Widgets and Components may be imported (import Hero from "@astrowind/Hero") or generated (added or updated) by the terminal command.

What do you think?

[djfdat]

For making the theme updateable, is this something that could be solved by forking the repo an merging updates to your fork?

I really like the idea of being able to install different parts individually. For example:

1. Create empty project using this theme, brings in the bare minimum for site information, but no routes.
2. Use the tool to manually create routes using certain page templates. This will pull in the page template and components.
3. In addition to having page templates, have templates for different sections of the page. The user can then run the tool to add new sections, which will pull in any additional components necessary, or delete sections, which will also check to see if any components are no longer used in any route and remove them from the file's imports.

[GrantBirki]

I would love to see some form of unit tests, linting, and astro checks built using CI (maybe GitHub Actions). Thank you!

[djfdat]

I don't know the limitations of Github Actions, but I' love if we had this + auto-update for important packages if all tests pass.

[djfdat]

First, I want to thank you for making such an amazing theme and sharing it with us. I'm new to web development, and this theme is just a great set of features built in for me to hack on top of. Forgive me if some of these things are already available, but here are my suggestions:

• Auth Pages (Login, Reset Password, Sign Up)
• Forms (could use Formsnap or Superforms under the hood)
• Integration with different backend services (Pocketbase, Astro DB, Supabase)
• Integration with different mailing list managers (Mailgun, Resend, etc.)
• Dashboards
• Charts (probably Chart.js and fun stuff built with it)
• Search
• Command Bar (For Dashboards, like this one from shadcn)
• More built in animations for different components to make them feel more lively

Here's a feature request that is a little outside of the realm of a template, but I would love to be able to enable a view that would show faint outlines with a nametag for each Astrowind Component. Ideally, this could be managed using The Astro Dev Toolbar.

Thanks again, and good luck!

[lionelduriez]

Offer the possibility to have per-environment configuration with different config.yaml files

Configuration of the web site can differ depending on the environment it is deployed to:

• Site URL
• Analytics
• etc.

A possible solution I have implemented: use environment variable NODE_ENV to choose the config file to load in src/integration/index.mjs.

The list of config files looks like:

• config.development.yaml
• config.staging.yaml
• config.production.yaml
• config.yaml (default configuration if no environment variable NODE_ENV has been provided)

[prototypa]

Hi @lionelduriez

Good point, thanks!

Does it seem like a solution to this that from the AstroWind integration configuration you could optionally pass the path from where to read the configuration file or the configuration directly?

Ex:

integrations: [
    // ...

    astrowind({
      // If 'string' is a path from which to read a configuration file of type JS, JSON or YAML.
      // If it is a JSON object, it is the configuration file itself.
      config: process.env.CONFIG_PATH // Ex: "src/config.development.yaml"
    }),
  ],

[lionelduriez]

Hi @prototypa

Handling the environment configuration in AstroWind integration configuration seems to be a good and clean solution.
So yes for this proposed solution !

[prototypa]

Hi @lionelduriez

Check to see if this implementation works for you:
https://github.com/onwidget/astrowind/blob/main/astro.config.mjs#L73

[lionelduriez]

Hi @prototypa

It works, thanks !

I have successfully tested per-environment configuration using latest astrowind code.
In my case, I use an environment variable to declare the path of the configuration file (tests are OK with relative path and absolute path).
My astro config looks like:

integrations: [
...
  astrowind({
    config: process.env.APP_CONFIG_PATH
  }),
],

When launching production build, command line looks like below on linux:

APP_CONFIG_PATH=./src/config.production.yaml astro build

[jovica-me]

Better color support.

• Currently there is no documentation on how to customize, use and the effect they have.
• I suggest adding tokens like primary, on primary, primary container and on primary container so the template provided components can be consistent.
• I suggest that colors should be completely moved from the config to CustomStyles.

There are many places where components mix tailwind colors and colors defined in the config for example in Headline.astro text-secondary dark:text-blue-200. It makes it harder to personalize the theme colors.

[prototypa]

Hi @jovica-me

• We agree that it is important to create good documentation about design tokens
• Can you please give us more details about these tokens you propose primary, on primary, primary container and on primary container or a reference to a design system that currently applies them?
• Why do you suggest moving colors from settings to CustomStyles.astro?

A note: what you notice now is a beginning or proof of concept for what we want to implement, but many more design tokens will be added and the code you see in CustomStyles will be encapsulated in a function within the integration. They can also be configured with a tool in the Astro Toolbar App.

[jovica-me]

Hello @prototypa

Relate to design tokens:

• Material design 3 specifically utilizes primary, on primary etc. Their theme builder is a great tool letting you create a theme and export all tokens as css variable. But, using the full md3 tokens is a double edged sword because it's opinionated. Forcing everyone to use it can be too much. On the other side, it would be simple to explain and use an already created token system. I am not advocating to add the component system and color system of md3 just the color tokens.
• Shadcn also has a good token system, which is similar to md3 just with different token names. It uses tailwind under the hood.
• Some color tokens I suggest adding are the shades of primary, secondary, tertiary; and tailwind/css that change with theme tokens for not just --aw-primary, but as well as what color is on top --aw-on-primary, background ...
• It's up to you to decided what's the best fit and needed tokens. If it was up to me, the md3 tokens are a perfect balance.

Related to CustomStyles and the config:

Personally I was lost for good 10 minutes trying to figure out why are color the same even though I removed them from the config. Then I saw the integration and figured it out.

• The only thing I would leave in the config is selecting the "defaultTheme".
• Tokens should be converted to completely use css and css variables. This would allow more transparency in how CSS is applied.
• You can still provide the theme default colors. Just place colors in for example styles/astowindtheme.css and import them in some main.css. Allowing you to move the tokens from CustomStyle to main.css . Removing the need for both config and CustomStyle and js imports/exports of colors.
• Plus if you plan on making a magical tool bar theme customizer, I assume you can just edit astowindtheme.css file and place tokens with specific colors in it.
• If somebody wants to remove config colors they can just remove the import from main.css, allow for css variables like --aw-primary to stay and not break tailwind and any future widgets and components you mentioned on making in a previous comment.

When I say main.css I am referring to a file with :root { --aw-primary:... } .dark { --aw-primary:... }, while astowindtheme.css has all the light, dark, and color shades like primary-100.

On the other side, I see why you would like to keep the colors in the config. It makes it easier to save and use them, making the code typesafe and everything.
If you plan on keeping the colors in the config, my suggestion is keeping the previously mentioned tokens and changes to the css. Instead of using CustomStyle to import config js colors to then just place it in a <style> tag that is included in the head, I think you can make (i dont know what its called in vite/rollup) a virtual css file astowindtheme and import it in main.css. This would still allow people to remove/edit the defaults and not break future components.

Didn't expect an answer so quickly, keep up the good work. 😁

[prototypa]

Hi @jovica-me

After thinking and thinking we have moved (as you recommended) all the design token configuration from config.yaml to CustomStyles.astro. You're right, the way we're working now is easier to understand.

We are defining new design tokens based on your proposals and other important Design Systems:

• https://www.designsystems.com/
• https://designsystemsrepo.com/design-systems/

It is a work in progress. When we have a proposal we will let you know.
Thank you.

[saadjavaid]

Integration with commenting services would be great. giscus maybe?

[JuliusBairaktaris]

Low priority: Fix all current Eslint errors to provide a cleaner codebase.

[kjartanvalur]

I would love to see more hero options. For example a full width image background with title and action buttons.