add doc for adding packages to pubspec.yaml

Author: pavanpodila

src/components/GoogleAnalytics.astro

@@ -0,0 +1,27 @@
+---
+export interface Props {
+  id: string;
+}
+
+const { id } = Astro.props
+
+const gtagUrl = `https://www.googletagmanager.com/gtag/js?id=${id}`
+---
+<!-- Global site tag (gtag.js) - Google Analytics -->
+<script async src={gtagUrl}></script>
+
+<script is:inline define:vars={{ id }}>
+  window.dataLayer = window.dataLayer || []
+
+  function gtag() {
+    dataLayer.push(arguments)
+  }
+
+  document.addEventListener('astro:page-load', () => {
+    gtag('js', new Date())
+
+    gtag('config', id)
+
+  }, { once: false })
+</script>
+

src/components/starlight/Head.astro

@@ -2,6 +2,7 @@
 import type { Props } from '@astrojs/starlight/props'
 import Default from '@astrojs/starlight/components/Head.astro'
 import { ViewTransitions } from 'astro:transitions'
+import GoogleAnalytics from '../GoogleAnalytics.astro'
 ---
 
 <Default {...Astro.props}>
@@ -10,22 +11,4 @@ import { ViewTransitions } from 'astro:transitions'
 
 <ViewTransitions />
 
-<!-- Google tag (gtag.js) -->
-<script async src="https://www.googletagmanager.com/gtag/js?id=G-3THXBRT184"></script>
-<script is:inline>
-  window.dataLayer = window.dataLayer || []
-
-  function gtag() {
-    dataLayer.push(arguments)
-  }
-</script>
-
-<script is:inline>
-  document.addEventListener('astro:page-load', () => {
-    gtag('js', new Date())
-
-    gtag('config', 'G-3THXBRT184')
-
-  }, { once: false })
-</script>
-
+<GoogleAnalytics id="G-3THXBRT184" />

src/components/starlight/SocialIcons.astro

@@ -6,10 +6,11 @@ import {Icon} from 'astro-icon/components'
 
 <div class="border-r border-gray-300 dark:border-gray-700 pr-4">
   <a href="https://vyuh.tech"
-     class={`font-bold text-accent-600 dark:text-accent-200 decoration-0 no-underline 
+     class={`font-bold decoration-0 no-underline 
+     text-accent-600 dark:text-accent-200
      px-2 py-0 
-     border border-gray-300 dark:border-gray-700 
-     hover:bg-accent-200 hover:dark:bg-accent-600 
+     border border-gray-300 dark:border-gray-700
+     hover:border-accent-600 dark:hover:border-accent-200
      rounded
      inline-flex items-center`}
   target="_blank" rel="noopener">

src/content/docs/guides/adding-packages.mdx

@@ -3,7 +3,7 @@ title: Adding Packages
 description: Learn how to add new packages to your Vyuh project.
 ---
 
-import { Aside, Steps } from '@astrojs/starlight/components'
+import { Aside, Steps, Badge } from '@astrojs/starlight/components'
 
 When adding packages to your Dart projects, there are two ways in which these
 packages can be referenced inside your `pubspec.yaml`.
@@ -23,7 +23,7 @@ dependencies:
 For a list of all the packages which are publicly available on `pub.dev`, refer
 to the [article on packages](/framework/packages).
 
-## Adding a package from the Enterprise Package Registry
+## Adding a package from the Enterprise <sup><Badge text='Plan' /></sup> Package Registry
 
 Adding a package from the private pub registry requires you to set up a token
 for the hosted provider. You will get this `token` during the onboarding process
@@ -36,7 +36,7 @@ provider as below.
 
     Keep the details of the hosted provider handy. You will need the URL of the
     hosted provider and the token to authenticate the requests. Let's capture
-    these in these variables for rest of the steps:
+    these with the following variables for rest of the steps:
 
     - `<token>`: secret token to authenticate requests to the hosted provider
     - `<private-pub-registry>`: URL of the hosted provider

src/content/docs/guides/designing-features.mdx

@@ -2,3 +2,161 @@
 title: Designing Features
 description: A set of tips for designing atomic and transferable features
 ---
+
+import { Aside } from '@astrojs/starlight/components'
+
+Designing a feature in the Vyuh framework requires putting together a bunch of
+elements. This includes the following:
+
+- **APIs** to talk to the backend to fetch data
+- **Experience layer** that renders the widgets on the screen and provides User
+  Interactivity
+  - Distilling the **Content Blocks** that make up the feature
+  - **Journeys** which allow the user to navigate from screen to screen in
+    exploring the content and interacting with it in different ways
+  - **Design system** components for a consistent experience
+  - Client side **State management** to keep track of User interactions
+  - **Analytics** to track user interactions and understand user behavior
+
+<Aside title={'Universal Truth about Applications'}>
+
+Although we talk about the **Vyuh Framework** in this article, the set of things
+that you have to do for building a feature for an application is _universally
+true_ and applicable across all applications.
+
+Whether you use a low-code tool or a no-code tool, the set of things you have to
+do pretty much remains the same. The Vyuh Framework however makes it easier to
+manage both functional and non-functional aspects of building a feature. This
+allows you to grow from an MVP to the scale of a Super App!
+
+</Aside>
+
+## Core Ideas
+
+Some of the core ideas of building a feature are already discussed in a separate
+article on [Features and Plugins](/concepts/features-and-plugins). Make sure to
+take a look at that before reading further.
+
+In this article, we'll focus more on applying the Vyuh Framework to build a
+feature. This is all about distilling the feature in terms of its schemas, APIs,
+and experience widgets.
+
+## Distilling a Feature
+
+As we've already seen in the article that was referenced before, a feature is
+essentially a collection of screens stitched together to form a journey. The
+content of each screen comes from a set of content blocks that you would design
+and configure from a CMS.
+
+![](images/feature-breakup.png)
+
+Now, it's possible that these content blocks may not have a CMS counterpart, and
+could be driven entirely from code. But for now, let's assume for a moment that
+we are designing features that are CMS connected, which allows dynamic
+configuration and flexibility for the business teams.
+
+Thus, the three core building blocks of any feature include the **APIs**, the
+**Content Blocks**, and **Journeys**. Let's see each of these in detail.
+
+![](images/feature-parts.png)
+
+### APIs
+
+APIs are the primary source of data for the feature. They could be REST APIs,
+GraphQL APIs, or even Websockets. The APIs are responsible for fetching the data
+that is required to render the content blocks on the screen.
+
+The APIs are also responsible for sending the user interactions back to the
+server for processing. This could be a simple form submission or a complex
+interaction that requires a series of steps to be completed.
+
+The Vyuh framework has a built-in component for working with APIs, called the
+`APIContent`. This can be configured from the CMS, making it easier for the
+business teams to change the type of data source that should be used to drive
+the content on the screen. The API content-block simplifies the configuration
+needed to show content on the screen, without burdening the business teams with
+the implementation details of the request headers, API keys or other security
+parameters that are required to fetch data from the endpoint.
+
+> Although we talk about APIs as the driving source of content for the content
+> block, it's possible that the content blocks come directly from the CMS. In
+> this case, they are configured on the CMS itself and rendered on the screen.
+
+#### API SDKs
+
+As you start working with more complex APIs and a large number of APIs, you will
+soon see a need to wrap all these APIs into an API SDK. The API SDK can expose a
+HTTP client that is used to fetch data from the server using semantic operations
+instead of talking directly to the endpoint URLs.
+
+The use of the API SDK also hides the details of deserializing the response
+payloads and creating Dart objects out of them. Additionally, these API SDKs can
+be tested independently and made sure that they are robust enough to work under
+various conditions and request parameters.
+
+When these APIs are commonly used across multiple features, the API SDK becomes
+the common package through which these features make those calls.
+
+In short, think of wrapping your APIs inside an API SDK and exposing it as a
+common package that can be used by multiple features when needed.
+
+### Content Blocks
+
+While the APIs focus on fetching data from a remote endpoint, the content blocks
+are the key elements that allow you to render this data inside a screen. These
+content blocks have two counterparts:
+
+- On the CMS where it exists as a schema, allowing business teams to configure
+  it.
+- On the Flutter side where it exists as a widget and possibly with the
+  combination of other elements like state management, dependency injection,
+  analytics, etc., which will all wrap together to provide the implementation
+  for the content block. Here is where you would also apply the **Design
+  System** to make the widgets visually consistent.
+
+<Aside title={'Design System as an SDK'}>
+  
+The Design System, just like the API-SDK, can be extracted into a separate
+package. This could be used across multiple features and even across apps if
+they are maintaining a similar visual identity.
+
+It's probably a good idea to start building your design system (themes, colors,
+typography, icons, spacings, and of course the UI components) into a separate
+package so it becomes more reusable across features & apps.
+
+</Aside>
+
+### Journeys
+
+Now we have included journeys as part of a feature which is purely from a
+customer's perspective.
+
+However, when we work with the Vyuh Framework, we think of the journeys as not
+being hardcoded into the feature itself. Instead, they are defined and
+configured from the CMS. This gives the business the ability to change the
+journeys on the fly depending on the type of customer,
+
+Externalizing the journeys is one of the key elements of the Vyuh Framework.
+With that, the features themselves only have to expose a set of content blocks,
+which are configured from the CMS. The business teams will use the content
+blocks to assemble pages and then stitch them together through a navigation
+journey.
+
+<Aside title={'Fixed Journeys'}>
+
+However, there are cases where a journey is so fixed in nature that it doesn't
+require a special type of configuration from the CMS. The payment journey is one
+such example.
+
+Once you check out from your cart, the payment journey begins and accepts your
+payment method, then takes you additional screens for more details, and finally
+completes the secure transaction. It then takes you back to the confirmation
+page. This journey can be hard-coded into the feature itself.
+
+</Aside>
+
+## Summary
+
+This guide has provided a set of tips for designing your features by identifying
+its core components. By applying these ideas you can even make features that
+work across a family of Vyuh Apps.

src/content/docs/guides/images/feature-breakup.png

@@ -4,4 +4,5 @@
 
 .mobile-preferences {
     @apply items-center justify-center;
-}
+}
+

src/content/docs/guides/images/feature-parts.png

@@ -22,7 +22,9 @@ const gray = {
 export default {
   content: ['./src/**/*.{astro,html,js,jsx,md,mdx,svelte,ts,tsx,vue}'],
   theme: {
-    colors: { accent, gray },
+    extend: {
+      colors: { accent, gray },
+    },
   },
   plugins: [starlight()],
 }

src/content/docs/guides/images/image (22).png

@@ -5,7 +5,8 @@
     "jsx": "react-jsx",
     "jsxImportSource": "react",
     "paths": {
-      "@/*": ["./src/*"]
+      "@/*": ["./src/*"],
+      "@docs/*": ["./src/content/docs/*"]
     }
   },
 }