Passing data to widgets like FAQs.astro?

[glenlong]

Love the template! Any plans to remove the hard-coded data in widgets like FAQs so that the content can be passed in via properties?

[prototypa]

Hello @glenlong

Thank you for communicating with us.
What you ask is something that we have been thinking since the beginning of this template. If it is better to make a group of components ready and with properties available for reuse, or if it is better to have a template with the most complex functionalities resolved and delegate the UI part to libraries already well made (Daisy UI, Flowbite. ..), or Tailwind CSS component online directories.

For now we have been moving through the latest variant, providing the basics in functionality and giving some widgets and letting each developer follow their path from there, also given the complexity of the design. It is something very personal and depends on the type of topic addressed.

However we are working on something that we will release soon that will help you choose specialized and custom widgets to make it a little easier to implement specialized sites using the template. We'll let you know as soon as we have it.

[glenlong]

Hey. Thanks for your reply and for the great work you're doing. I'm not familiar with those other libraries so I don't have a good grasp of the trade-offs. I'm just seeing how small changes to what you already have could potentially make a big difference.

For instance, the FAQs.astro component already uses an array to feed data to the HTML. But if I want to use that component in my site, I have no choice but to edit the code of the component.

However, if the array of data was passed as a simple parameter I could use the FAQs.astro widget as-is, without editing the code. I could also have multiple FAQs on my site with different data, all using the same component.

Hope that makes sense!

[prototypa]

Hello @glenlong,

I've been thinking a lot about your suggestion and I'm working on it. Making a first test of how to make each component well configurable and at the same time easy to use. As soon as I have a first preview ready, I'll upload it to a branch and share it with you in case you want to collaborate or give your feedback.

Thank you, we will be in touch. Any other suggestion you have, please let me know.

[glenlong]

Thanks for the quick response. Happy to give future feedback. It might help if I give my situation. I really like your design and although I have coding experience I don't want my website to turn into a coding project. I want to use as much of your design and code as possible and fit my content and data into that framework. So if I can use a component without making any changes and get future updates without worrying about integrating my changes, that works well for me. I realise other people will be using your code simply as a starting point but in my case I want to change as little as possible. Hope that makes sense.

[prototypa]

@glenlong

Please take a look at this example of a widget migrated to props and tell me what you think. There are some complexities in using it and we have decided for now to use a combination of Astro.props with <slots>.

For example, in the case of <Hero> and according to these properties, we could instantiate it in different ways:

Case 1:

---
import Hero from '~/components/widgets/Hero.astro';
---

<Hero
  title="Hello Hero"
  subtitle="Lorem ipsum lorem"
  callToAction1={{
    text: "Get started",
    href: "#",
    icon: "tabler:arrow-down-right"
  }}
  callToAction2={{
    text: "Learn more",
    href: "#"
  }}
  image={{
    src: import('~/assets/images/hero.png'),
    alt: ""
  }}
/>

Case 2:

---
import Hero from '~/components/widgets/Hero.astro';

const heroData= {
  title: "Hello Hero",
  subtitle: "Lorem ipsum lorem",
  callToAction1: {
    text: "Get started",
    href: "#",
    icon: "tabler:arrow-down-right"
  },
  callToAction2: {
    text: "Learn more",
    href: "#"
  },
  image: {
    src: import('~/assets/images/hero.png'),
    alt: "Some alt"
  }
}
---

<Hero
  {...heroData}
/>

Case 3:

---
import { Picture } from '@astrojs/image/components';
import Hero from '~/components/widgets/Hero.astro';
---

<Hero
  subtitle="Lorem ipsum lorem"
  callToAction1={{
    text: "Get started",
    href: "#",
    icon: "tabler:arrow-down-right"
  }}
  callToAction2={{
    text: "Learn more",
    href: "#"
  }}
>
  <Fragment slot="title">
    Title with some mix between <strong>Text</strong> and <strong>Html</strong>
  </Fragment>
  <Fragment slot="image">
    <Picture
      src={import('~/assets/images/hero.png')}
      alt="Some alt"
      class="mx-auto rounded-md w-full"
      widths={[400, 768, 1480]}
      sizes="(max-width: 767px) 400px, (max-width: 1479px) 768px, 1480px"
      aspectRatio={1480 / 833}
      loading="eager"
      width={1480}
      height={833}
    />
  </Fragment>
</Hero>

This is the source code of the example <Hero> widget:

---
import { Icon } from 'astro-icon';
import { Picture } from '@astrojs/image/components';

interface CallToAction {
  text: string;
  href: string;
  icon?: string;
}

export interface Props {
  title?: string;
  subtitle?: string;
  callToAction1?: string | CallToAction;
  callToAction2?: string | CallToAction;
  image?: string | any; // TODO: find HTMLElementProps
}

const {
  title = await Astro.slots.render('title'),
  subtitle = await Astro.slots.render('subtitle'),
  callToAction1 = await Astro.slots.render('callToAction1'),
  callToAction2 = await Astro.slots.render('callToAction2'),
  image = await Astro.slots.render('image'),
} = Astro.props;
---

<section>
  <div class="max-w-6xl mx-auto px-4 sm:px-6">
    <div class="py-12 md:py-20">
      <div class="text-center pb-10 md:pb-16 max-w-5xl mx-auto">
        {
          title && (
            <h1
              class="text-5xl md:text-[3.50rem] font-bold leading-tighter tracking-tighter mb-4 font-heading"
              set:html={title}
            />
          )
        }
        <div class="max-w-3xl mx-auto">
          {subtitle && <p class="text-xl text-gray-600 mb-8 dark:text-slate-400" set:html={subtitle} />}
          <div class="max-w-xs sm:max-w-md m-auto flex flex-nowrap flex-col sm:flex-row sm:justify-center gap-4">
            {
              callToAction1 && (
                <div class="flex w-full sm:w-auto">
                  {typeof callToAction1 === 'string' ? (
                    <Fragment set:html={callToAction1} />
                  ) : (
                    <a class="btn btn-primary sm:mb-0 w-full" href={callToAction1?.href} target="_blank" rel="noopener">
                      {callToAction1?.icon && <><Icon name={callToAction1.icon} class="w-5 h-5 mr-1 -ml-1.5" />{' '}</>}
                      {callToAction1?.text}
                    </a>
                  )}
                </div>
              )
            }
            {
              callToAction2 && (
                <div class="flex w-full sm:w-auto">
                  {typeof callToAction2 === 'string' ? (
                    <Fragment set:html={callToAction2} />
                  ) : (
                    <a class="btn w-full" href={callToAction2?.href}>
                      {callToAction2?.icon && <><Icon name={callToAction2.icon} class="w-5 h-5 mr-1 -ml-1.5" />{' '}</>}
                      {callToAction2.text}
                    </a>
                  )}
                </div>
              )
            }
          </div>
        </div>
      </div>
      <div>
        {
          image && (
            <div class="relative m-auto max-w-4xl">
              {typeof image === 'string' ? (
                <Fragment set:html={image} />
              ) : (
                <Picture
                  class="mx-auto rounded-md w-full"
                  widths={[400, 768, 1480]}
                  sizes="(max-width: 767px) 400px, (max-width: 1479px) 768px, 1480px"
                  aspectRatio={1480 / 833}
                  loading="eager"
                  width={1480}
                  height={833}
                  {...image}
                />
              )}
            </div>
          )
        }
      </div>
    </div>
  </div>
</section>

[glenlong]

Many thanks for exploring this further. Here are my thoughts:

Case 1: I think this is my preferred method. I ended up doing something similar in my own code, although I flattened out the properties. I also used a slot where the content was most likely to have its own internal structure (paragraphs, etc.)

	<Hero title="Course Creation Help without the Hype"
		image="~assets/images/board.jpg"
		btnOneText="Book a Call"
		btnOneUrl="https://www.calendly.com/glenlong/clarity"
		btnOneIcon="tabler:phone"
		btnTwoText="Get the Newsletter"
		btnTwoUrl="https://glenlong.ck.page/10385b00fe"
		btnTwoIcon="tabler:mail">
		<span>I help successful coaches, consultants and authors increase their income and impact by turning their expertise into kick-ass digital training programs.</span>
	</Hero>

Overall I think Case 1 does a good job of abstracting out the data while still making it simple to use and read. For more complex components it may get to the point where there are too many parameters, but I guess it's a design decision about what is and isn't configurable without editing the component itself.

Case 2: I think this is a bit uglier, but still achieves the goal of making the component reusable. It will also work for any data that needs to be passed because the structure of the data object can just adapt to what's needed. I don't particularly like it, but it works. :-)

Case 3: This is my least favourite option because it pulls too much of the component out into the code that imports it. It's very flexible for sure, but it starts to dilute the meaning of the component itself.

For me, the design goal would be this:

Add just enough parameters so that someone could use your design exactly as-is - same layout, same image sizes, same colours, etc. - but just configure those bits of content that anyone would need to change, e.g., the heading text, the descriptions, the button text, the icons, the links, etc.

If someone wants to change the design aspects, they can copy the component and make their own edits. But people who want to change as little as possible can do it just with parameters.

Hope that makes sense!

[prototypa]

Thank you very much for the detailed answer @glenlong

Maybe I didn't explain myself well. The way the example Hero component is implemented, you can use either case. It is your decision according to the needs you have.

If you want to keep it simple like React, you can use Case 1, if you want to save your data in separate files so as not to have the code of each page very cluttered you can use Case 2 and if you need flexibility to pass complex HTML to each property you can use the case 3. The component supports all those forms. You don't have to limit yourself to any.

[glenlong]

Ah okay. Yes I think we are misunderstanding each other a little. :-)

I understand that there are various different ways for me to adapt your code to my needs. What I was saying was that if the components in your repository supported some basic parameters, it would make it even easier for someone like me to create a site following your design without having to edit the component files themselves. I could just send configuration parameters via the page that imports them.

Since you need to include some sample content in your components content anyway, why pass that content into the component via parameters instead of hard-coding it in the components themselves?

[prototypa]

Hello @glenlong, I have a new AstroWind update:

https://astrowind.vercel.app/

Please take a look at how to use the widgets in index.astro and let me know if that works for you.

The logic here is the following: most of the time with passing Props you will solve all the problems, but sometimes you may want to pass a more complex HTML to some sections of the widgets and that is why internally Astro Slots are also accepted on some properties.

For example, to pass the necessary properties for the Features Widget I didn't need to use slots, I just imported the widget and passed properties to it:

astrowind/src/pages/index.astro

Line 53 in 58484df

<Features

  <Features
    highlight="Features"
    title="What you get with AstroWind"
    subtitle="Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque rem aperiam, eaque ipsa quae."
    items={[
      [
        {
          title: 'Astro + Tailwind CSS Integration',
          description:
            'A seamless integration between two great frameworks that offer high productivity, performance and versatility.',
          icon: 'tabler:brand-tailwind',
        },
        {
          title: 'Ready-to-use Components',
          description:
            'Widgets made with Tailwind CSS ready to be used in Marketing Websites, SaaS, Blogs, Personal Profiles, Small Business...',
          icon: 'tabler:components',
        },
        {
          title: 'Best Practices',
          description:
            'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi sagittis, quam nec venenatis lobortis, mi risus tempus nulla.',
          icon: 'tabler:list-check',
        },
      ],
      [
        {
          title: 'Excellent Page Speed',
          description:
            'Having a good page speed impacts organic search ranking, improves user experience (UI/UX) and increase conversion rates.',
          icon: 'tabler:rocket',
        },
        {
          title: 'Search Engine Optimization (SEO)',
          description:
            'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi sagittis, quam nec venenatis lobortis, mi risus tempus nulla.',
          icon: 'tabler:arrows-right-left',
        },
        {
          title: 'Open to new ideas and contributions',
          description:
            'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi sagittis, quam nec venenatis lobortis, mi risus tempus nulla.',
          icon: 'tabler:bulb',
        },
      ],
    ]}
  />

But in the case of CallToAction Widget I want to pass some little HTML to some properties and instead of passing the html as text I preferred to use slots, but is not necessary:

https://github.com/onwidget/astrowind/blob/58484dfca8d19f19cd187e15b47da11f13afaf6f/src/pages/index.astro#LL338C2-L353C17

  <CallToAction
    callToAction={{
      text: 'Get template',
      href: 'https://github.com/onwidget/astrowind',
      icon: 'tabler:download',
    }}
  >
    <Fragment slot="title">
      Astro + <br class="block sm:hidden" /><span class="sm:whitespace-nowrap">Tailwind CSS</span>
    </Fragment>

    <Fragment slot="subtitle">
      Be very surprised by these huge fake numbers you are seeing on this page. <br class="hidden md:inline" />Don't
      waste more time! :P
    </Fragment>
  </CallToAction>

Soon we will upload new Widgets that we are working on, including Testimonials, Prices, Team, more Features, Contents and some useful pages such as About Us or Contact.

Waiting for your feedback, thank you.

[glenlong]

Hi @prototypa,

Love the updates! I agree it makes sense to use slots in certain places.

I think you are doing this anyway, but it would be good to make sure that consistent property names are used across all the widgets, e.g., title, subtitle, description, etc.

One other quick thought. You have several Features widgets, which is great. but Features1, Features2 is not very descriptive.

Also I think maybe Features2 in AstroWind is a different layout to Features2 in TailNext, which could cause confusion later on.

I wonder if maybe there is a way to name the widgets which is not too long, but more descriptive.

For example:

FeaturesListPlusImage
FeaturesCardGrid

These may not be quite right but hopefully you get the idea.

Let me know what you think!

[prototypa]

Thanks @glenlong

I agree with you. It just takes a little time.

Before, the widgets had a logical name, but to date I was not sure which ones I would leave and some looked almost the same to me and I decided to put numbers on them as the project was taking shape. When releasing version 1 all widgets will have a semantic name.

Regarding the number of properties and names, I'm still playing with it until I find a structured and simple way to do it. But I still agree with you, it would be very useful to develop faster.

Thanks for all the feedback.

[glenlong]

Makes sense. As for feedback - you're welcome. Happy to help.

Here's a quick idea about a standard property to add: id. This would add a custom id to the

element so you can target that section of the page using an anchor.

I noticed some widgets, like Features, have that hard-coded, but others don't have it at all.