Merge remote-tracking branch 'origin/dev' into fix/CallToAction-index-prop

Author: TylerAPfledderer

.all-contributorsrc

@@ -100,7 +100,7 @@ body:
     id: layer_2_dapp_ecosystem
     attributes:
       label: Link to dapp ecosystem (if applicable)
-      description: "Please provide a link to the dapp ecosystem. (ex: https://portal.arbitrum.one/, https://www.optimism.io/apps/all)"
+      description: "Please provide a link to the dapp ecosystem. (ex: https://portal.arbitrum.io/, https://www.optimism.io/apps)"
   - type: input
     id: layer_2_token_contract_list
     attributes:

.github/ISSUE_TEMPLATE/suggest_layer2.yaml

@@ -1,21 +1,21 @@
-"review needed :eyes:":
+"needs review 👀":
   - src/**/*
   - public/*
 
-"documentation :book:":
+"documentation 📖":
   - README.md
 
-"tooling :wrench:":
+"tooling 🔧":
   - .github/**/*
   - src/scripts/*
   - src/lib/*
   - src/hooks/*
 
-"dependencies :package:":
+"dependencies 📦":
   - package.json
   - yarn.lock
 
-"internal :house:":
+"internal 🏠":
   - .all-contributorsrc
   - i18n.config.json
   - next.config.js
@@ -29,14 +29,14 @@
   - .prettierrc
   - netlify.toml
 
-"translation :earth_africa:":
+"translation 🌍":
   - src/content/translations/**/*
   - src/intl/**/*
   - src/lib/utils/translations.ts
 
-"content :fountain_pen:":
+"content 🖋️":
   - src/pages/*
   - public/content/**/*
 
-"event :date:":
+"event 📅":
   - src/data/community-events.json

.github/labeler.yml

@@ -59,5 +59,5 @@ jobs:
 
       - name: Create Pull Request
         run: |
-          gh auth login --with-token <<< ${{ secrets.GITHUB_TOKEN }}
+          gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}
           gh pr create --base dev --head "automated-update-${{ env.TIMESTAMP }}" --title "Update translation contributors from Crowdin - ${{ env.READABLE_DATE }}" --body-file pr_body.txt

.github/workflows/get-crowdin-contributors.yml

@@ -60,5 +60,5 @@ jobs:
 
       - name: Create Pull Request
         run: |
-          gh auth login --with-token <<< ${{ secrets.GITHUB_TOKEN }}
+          gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}
           gh pr create --base dev --head "automated-update-${{ env.TIMESTAMP }}" --title "Update translation progress from Crowdin - ${{ env.READABLE_DATE }}" --body-file pr_body.txt

.github/workflows/get-translation-progress.yml

@@ -0,0 +1,59 @@
+name: Import community events
+
+on:
+  schedule:
+    - cron: "0 0 * * SUN" # Runs every Sunday at midnight
+  workflow_dispatch:
+
+jobs:
+  create_pr:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out code
+        uses: actions/checkout@master
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18
+
+      - name: Install dependencies
+        run: yarn install
+
+      - name: Set up git
+        run: |
+          git config --global user.email "[email protected]"
+          git config --global user.name "GitHub Action"
+
+      - name: Generate timestamp and readable date
+        id: date
+        run: |
+          echo "TIMESTAMP=$(date +'%Y%m%d%H%M%S')" >> $GITHUB_ENV
+          echo "READABLE_DATE=$(date +'%B %-d')" >> $GITHUB_ENV
+
+      - name: Fetch latest dev and create new branch
+        run: |
+          git fetch origin dev
+          git checkout -b "automated-update-${{ env.TIMESTAMP }}" origin/dev
+
+      - name: Run script
+        run: yarn events-import
+        env:
+          GOOGLE_API_KEY: ${{ secrets.GOOGLE_API_KEY }}
+
+      - name: Commit and push
+        run: |
+          git add -A
+          git commit -m "Update community events"
+          git push origin "automated-update-${{ env.TIMESTAMP }}"
+
+      - name: Create PR body
+        run: |
+          echo "This PR was automatically created to update community events from external community spreadsheet." > pr_body.txt
+          echo "This workflows runs every Sunday at 00:00 (UTC)." >> pr_body.txt
+          echo "Source: https://docs.google.com/spreadsheets/d/1NEu_FCc1hnGAuRgPmbXXpf0h2lCrCOlMKbbFEqgkVDQ" >> pr_body.txt
+
+      - name: Create Pull Request
+        run: |
+          gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}
+          gh pr create --base dev --head "automated-update-${{ env.TIMESTAMP }}" --title "Update community events from external spreadsheet - ${{ env.READABLE_DATE }}" --body-file pr_body.txt

.github/workflows/import-community-events.yml

@@ -17,5 +17,5 @@ jobs:
               issue_number: context.issue.number,
               owner: context.repo.owner,
               repo: context.repo.repo,
-              labels: ["needs-triage"]
+              labels: ["needs triage 📥"]
             })

.github/workflows/issue-triage-label.yml

@@ -18,7 +18,7 @@ It's as easy as running `yarn storybook` to boot up a dedicated localhost to see
 
 ## Setting up a component's stories
 
-> 🚨 NOTE: This project uses Storybook v7. The following documentation outlines preferences in setup as it relates to this version. You can refer to the [main docs](https://storybook.js.org/docs/get-started/install) if you need any additional details
+> 🚨 NOTE: This project uses Storybook v7, using the Component Story Format v3 and the `satisfies` keyword to define the type of the meta object. The following documentation outlines preferences in setup as it relates to this version. You can refer to the [main docs](https://storybook.js.org/docs/get-started) if you need any additional details
 
 A Storybook "story" is an instance of a component in a certain state or with certain parameters applied to show an alternative version of the component.
 
@@ -57,9 +57,11 @@ export const Basic: Story = {
 
 **Note**: with the `title` option, we write this based on the groupings set by the Design System. Groupings are declared with forward slashes. (i.e. `Atoms / Form / Input`). See the Storybook docs for details on [Naming conventions](https://storybook.js.org/docs/7.0/react/writing-stories/naming-components-and-hierarchy)
 
+Also, please view the Figma file for the [proposed structure for the Design System](https://www.figma.com/file/Ne3iAassyfAcJ0AlgqioAP/DS-to-storybook-structure?type=design&node-id=42%3A50&mode=design&t=RGkyouvTilzF42y0-1) to provide the correct groupings.
+
 We will maintain this structure for every story file, regardless of simplicity.
 
-Should the component accept props on all or some renders, you can provide an `args` prop for each story and supply the necessary data. And if there is children, use the `render` prop to pass the args and supply children elements.
+Should the component accept props on all or some renders, you can provide an `args` prop for each story and supply the necessary data. This can be done in place of the render if only a single instance of the given component is needed with no other components. If the `children` prop is used, it can still be used in the `args` prop.
 
 Let's say for a `Button` component with different style variants...
 
@@ -77,15 +79,15 @@ export default meta
 type Story = StoryObj<typeof meta>;
 
 export const Solid: Story = {
-  render: (args) => <Button {...args}>A Button</Button>,
   args: {
     variant: 'solid',
+    children: 'A Button'
   }
 }
 export const Outline: Story = {
-  render: (args) => <Button {...args}>A Button</Button>,
   args: {
     variant: 'outline',
+    children: 'A Button'
   }
 }
 
@@ -94,26 +96,51 @@ export const Outline: Story = {
  * they should be shown under one story, so they can be seen side-by-side in the GUI
  * for reviewers to easily compare.
  * This can also be done for various sizes or other like alterations
+ *
+ * 🚨 If prop content is supplied directly to the component and the `args` prop is not used,
+ * do not use the `StoryObj` type. This is especially important when a story rendering multiple versions
+ * of the component.
  */
 
 // Assuming `solid` is the default variant in the Chakra theme config
-export const Variants = () => (
-  <VStack>
-    <Button>A Solid Button</Button>
-    <Button variant="outline">An Outline Button</Button>
-    <Button variant="unstyled">An Unstyled Button</Button>
-  </VStack>
-)
+export const Variants = {
+  render: () => (
+    <VStack>
+      <Button>A Solid Button</Button>
+      <Button variant="outline">An Outline Button</Button>
+      <Button variant="unstyled">An Unstyled Button</Button>
+    </VStack>
+  )
+}
 ```
 
-If only one story is provided for a component, the name of the exported object should match the name in the `title` meta option. (If the title is `Atoms / Form / Button` then the object should be named `Button`) This will hoist the display name up to the parent level in the Storybook dashboard's sidebar.
+### Story file containing a single story
+
+If only one story is provided for a component, the name of the exported object should match the name in the `title` meta option. (If the title is `Atoms / Form / Button` then the object should be named `Button`) This will hoist the display name up to the parent level in the Storybook dashboard's sidebar. This will also mean you have to rename the import of the component. Call it `ButtonComponent`, say.
+
+```tsx
+import ButtonComponent from "."
+
+const meta = {
+  title: "Atoms / Form / Button",
+  component: ButtonComponent,
+} satisfies Meta<typeof ButtonComponent>
+
+export default meta
+
+export const Button: StoryObj<typeof meta> = {
+  render: () => <ButtonComponent />,
+}
+```
 
 As you go and make adjustments to the component itself or it's variant styles, Storybook will hot reload and those changes will appear in the stories that emphasize them.
 
 ## Storybook Dashboard
 
 The dashboard where you view each story has a number of different addons available to check the story thoroughly.
 
+![Screenshot of Storybook Dashboard for Ethereum.org](https://github.com/ethereum/ethereum-org-website/assets/65234762/7dea7692-6a6d-4f1c-b7cb-db177bcab44d)
+
 Outlined below are each area going from left to right in the selections.
 
 | Toolbar above the preview                | Panel below the preview                                                                                                                                                                                                                                                    |

README.md

@@ -4,17 +4,17 @@ This documentation outlines the current process for how issues are triaged for t
 
 ## Issue creation process
 
-Whenever a new issue is opened, it will automatically be labeled with a `needs-triage` label. The `needs-triage` label means that the core team needs to look at the issue, and nobody should work on it yet to avoid unnecessary work. This label will be removed after the issue has been triaged by a core contributor.
+Whenever a new issue is opened, it will automatically be labeled with a `needs triage 📥` label. The `needs triage 📥` label means that the core team needs to look at the issue, and nobody should work on it yet to avoid unnecessary work. This label will be removed after the issue has been triaged by a core contributor.
 
 ## Triage process
 
-The core team will review issues with the `needs-triage` label within 5 days. In order for an issue to be considered triaged, one of the following will need to happen:
+The core team will review issues with the `needs triage 📥` label within 5 days. In order for an issue to be considered triaged, one of the following will need to happen:
 
 1. The issue will be closed if it is not needed, a duplicate, or spam.
 2. If an issue needs more discussion, the `GH grooming` tag will be added, and the issue will be discussed next GitHub grooming. After this call, action items will be recorded and the issue will be considered triaged.
 3. The issue is labeled with the appropriate tags for work needed (ex: `design required`, `dev required`, etc.) and open it up for assignment. More on this below.
 
-After an issue has been triaged, the `needs-triage` label will be removed from the issue.
+After an issue has been triaged, the `needs triage 📥` label will be removed from the issue.
 
 ## Assignment process