eddev 0.2.28 → 0.2.31

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (92) hide show
  1. package/build/get-webpack-config.js +1 -0
  2. package/gravityforms/useGravityForm.js +13 -3
  3. package/package.json +6 -5
  4. package/serverless-template/tsconfig.json +1 -0
  5. package/style/createStitches.js +10 -3
  6. package/docs_old/README.md +0 -33
  7. package/docs_old/babel.config.js +0 -3
  8. package/docs_old/blog/2019-05-28-first-blog-post.md +0 -12
  9. package/docs_old/blog/2019-05-29-long-blog-post.md +0 -44
  10. package/docs_old/blog/2021-08-01-mdx-blog-post.mdx +0 -20
  11. package/docs_old/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg +0 -0
  12. package/docs_old/blog/2021-08-26-welcome/index.md +0 -25
  13. package/docs_old/blog/authors.yml +0 -17
  14. package/docs_old/docs/graphql/1.graphql-overview.md +0 -62
  15. package/docs_old/docs/graphql/2.query-hooks.md +0 -238
  16. package/docs_old/docs/graphql/3.extending-wpgraphql.md +0 -3
  17. package/docs_old/docs/graphql/_category_.json +0 -4
  18. package/docs_old/docs/graphql/img/graphql-ide.png +0 -0
  19. package/docs_old/docs/graphql/img/infinite-example.gif +0 -0
  20. package/docs_old/docs/graphql/img/mutation-example.gif +0 -0
  21. package/docs_old/docs/gutenberg/1.overview.md +0 -25
  22. package/docs_old/docs/gutenberg/2.block-definition.md +0 -37
  23. package/docs_old/docs/gutenberg/3.block-acf.md +0 -13
  24. package/docs_old/docs/gutenberg/4.block-graphql.md +0 -63
  25. package/docs_old/docs/gutenberg/5.inline-editing.md +0 -33
  26. package/docs_old/docs/gutenberg/6.nested-blocks.md +0 -80
  27. package/docs_old/docs/gutenberg/7.restricting-to-post-types.md +0 -38
  28. package/docs_old/docs/gutenberg/8.restricting-to-page-templates.md +0 -26
  29. package/docs_old/docs/gutenberg/9.dynamic-blocks.md +0 -21
  30. package/docs_old/docs/gutenberg/_category_.json +0 -4
  31. package/docs_old/docs/gutenberg/img/create-acf-fields-for-block.png +0 -0
  32. package/docs_old/docs/gutenberg/img/example-acf-single-project-tile.png +0 -0
  33. package/docs_old/docs/how-to/1.new-site.md +0 -36
  34. package/docs_old/docs/how-to/2.deployment.md +0 -31
  35. package/docs_old/docs/how-to/3.menus.md +0 -72
  36. package/docs_old/docs/how-to/4.options-pages.md +0 -41
  37. package/docs_old/docs/how-to/5.bundle-size.md +0 -177
  38. package/docs_old/docs/how-to/6.favicons.md +0 -82
  39. package/docs_old/docs/how-to/_category_.json +0 -4
  40. package/docs_old/docs/how-to/img/bundle-analysis-after.png +0 -0
  41. package/docs_old/docs/how-to/img/bundle-analysis-before.png +0 -0
  42. package/docs_old/docs/how-to/img/bundle-webpack-after.png +0 -0
  43. package/docs_old/docs/how-to/img/bundle-webpack-before.png +0 -0
  44. package/docs_old/docs/how-to/img/favicon-codebase.png +0 -0
  45. package/docs_old/docs/how-to/img/favicon-figma-export.png +0 -0
  46. package/docs_old/docs/how-to/img/favicon-figma.png +0 -0
  47. package/docs_old/docs/intro.md +0 -7
  48. package/docs_old/docs/known-issues.md +0 -8
  49. package/docs_old/docs/serverless/1.overview.md +0 -1
  50. package/docs_old/docs/serverless/2.config.md +0 -1
  51. package/docs_old/docs/serverless/3.wordpress-vercel.md +0 -8
  52. package/docs_old/docs/serverless/4.apis.md +0 -1
  53. package/docs_old/docs/serverless/5.rpc.md +0 -1
  54. package/docs_old/docs/serverless/_category_.json +0 -4
  55. package/docs_old/docs/stack/1-WordPress.md +0 -18
  56. package/docs_old/docs/stack/2-Flywheel.md +0 -15
  57. package/docs_old/docs/stack/3-React.md +0 -12
  58. package/docs_old/docs/stack/4-TypeScript.md +0 -13
  59. package/docs_old/docs/stack/5-WPGraphQL.md +0 -21
  60. package/docs_old/docs/stack/6-eddev.md +0 -9
  61. package/docs_old/docs/stack/_category_.json +0 -4
  62. package/docs_old/docs/tooling/1.scripts.md +0 -25
  63. package/docs_old/docs/tooling/2.aliases.md +0 -13
  64. package/docs_old/docs/tooling/3.defines.md +0 -13
  65. package/docs_old/docs/tooling/4.config-file.md +0 -14
  66. package/docs_old/docs/tooling/_category_.json +0 -4
  67. package/docs_old/docs/views/1.overview.md +0 -31
  68. package/docs_old/docs/views/2.queries.md +0 -18
  69. package/docs_old/docs/views/3.content-blocks.md +0 -36
  70. package/docs_old/docs/views/4.app-view.md +0 -35
  71. package/docs_old/docs/views/5.page-templates.md +0 -20
  72. package/docs_old/docs/views/_category_.json +0 -4
  73. package/docs_old/docusaurus.config.js +0 -119
  74. package/docs_old/package.json +0 -40
  75. package/docs_old/sidebars.js +0 -26
  76. package/docs_old/src/components/HomepageFeatures.js +0 -64
  77. package/docs_old/src/components/HomepageFeatures.module.css +0 -11
  78. package/docs_old/src/css/custom.css +0 -28
  79. package/docs_old/src/pages/index.js +0 -36
  80. package/docs_old/src/pages/index.module.css +0 -23
  81. package/docs_old/src/pages/markdown-page.md +0 -7
  82. package/docs_old/static/.nojekyll +0 -0
  83. package/docs_old/static/img/docusaurus.png +0 -0
  84. package/docs_old/static/img/favicon.ico +0 -0
  85. package/docs_old/static/img/logo-black.svg +0 -4
  86. package/docs_old/static/img/logo-white.svg +0 -4
  87. package/docs_old/static/img/tutorial/docsVersionDropdown.png +0 -0
  88. package/docs_old/static/img/tutorial/localeDropdown.png +0 -0
  89. package/docs_old/static/img/undraw_docusaurus_mountain.svg +0 -170
  90. package/docs_old/static/img/undraw_docusaurus_react.svg +0 -169
  91. package/docs_old/static/img/undraw_docusaurus_tree.svg +0 -1
  92. package/docs_old/yarn.lock +0 -8814
@@ -1,82 +0,0 @@
1
- # Favicons
2
-
3
- Since `eddev@0.2.0`, favicons are automatically included in every page, in both serverless and WordPress. All you need to do is export the icons straight from Figma!
4
-
5
- ## Exporting the icons
6
-
7
- 1. Navigate to the **🍒 oGraph & Icons** page in Figma
8
- 2. Select all the icons on the right
9
- 3. Activate the **Export** tab in the sidebar
10
- 4. Export with default settings to the `assets` folder in your theme.
11
- 5. Run `yarn dev` to regenerate the `favicon.ico` file, which is used as a fallback. The `<head>` is published automatically.
12
-
13
- :::tip
14
- See the bottom of this page for screenshots!
15
- :::
16
-
17
- ## `favicon.ico`
18
-
19
- When you run `yarn dev` or `yarn build`, a `favicon.ico` is automatically generated for you!
20
-
21
- It uses the uses the pattern `assets/favicon/favicon-*.png`, which usually means it'll be composed using `favicon-16x16.png`, `favicon-32x32.png` and `favicon-96x96.png`.
22
-
23
- ## Light & Dark Mode Icons
24
-
25
- Not all browsers support SVG favicons, but they're a great way to optionally support light/dark mode. You can right-click and 'Copy as SVG', and then add appropriate styling. Save to `assets/favicon/favicon.svg`, and it'll automatically be added to the `<head>` tag.
26
-
27
- See below for an example:
28
-
29
- ```svg title="assets/favicon/favicon.svg"
30
- <svg width="16" height="16" viewBox="0 0 16 16" fill="none"
31
- xmlns="http://www.w3.org/2000/svg">
32
- <style>
33
- path {
34
- fill: #000000;
35
- }
36
- @media (prefers-color-scheme: dark) {
37
- path {
38
- fill: #ffffff;
39
- }
40
- }
41
- </style>
42
- <path d="..." />
43
- </svg>
44
- ```
45
-
46
- ## Meta Tags
47
-
48
- The appropriate `<link />` tags are automatically added to your `<head>` tag, so you don't need to worry about it. Note that these tags only appear if they're found in the correct folder (`assets/favicon/`).
49
-
50
- ## Filenames
51
-
52
- The following files are expected to be found. Note that if they are missing, there are no errors!
53
-
54
- ```
55
- /assets/favicons/favicon.svg
56
- /assets/favicons/120x120.png
57
- /assets/favicons/128x128.png
58
- /assets/favicons/196x196.png
59
- /assets/favicons/apple-touch-icon-120x120.png
60
- /assets/favicons/apple-touch-icon-152x152.png
61
- /assets/favicons/apple-touch-icon-167x167.png
62
- /assets/favicons/apple-touch-icon-180x180.png
63
- /assets/favicons/favicon-16x16.png
64
- /assets/favicons/favicon-32x32.png
65
- /assets/favicons/favicon-96x96.png
66
- /assets/favicons/windows-270x270.png
67
- /assets/favicons/windows-70x70.png
68
- ```
69
-
70
- ## Screenshots of export steps
71
-
72
- Select all the icons, skipping the labels:
73
-
74
- ![Figure A. Select all icons](./img/favicon-figma.png)
75
-
76
- Export your selection:
77
-
78
- ![Figure B. Export them](./img/favicon-figma-export.png)
79
-
80
- Your codebase should look like this after you've exported them. Note that if you instead see an `App icon` folder, you should rename this to `favicon` and ensure that it matches as below:
81
-
82
- ![Figure C. You should now have a 'favicons' folder](./img/favicon-codebase.png)
@@ -1,4 +0,0 @@
1
- {
2
- "label": "🧐 How To",
3
- "position": 20
4
- }
@@ -1,7 +0,0 @@
1
- ---
2
- sidebar_position: 1
3
- ---
4
-
5
- # 👋 Intro
6
-
7
- Welcome! Use the sidebar on the left to find what you're looking for.
@@ -1,8 +0,0 @@
1
- ---
2
- sidebar_position: 100
3
- ---
4
-
5
- # Known Issues
6
-
7
- - Fragments from `/queries/fragments` don't run in GraphiQL IDE
8
- - Block ACF fields cannot be queried in the GraphiQL IDE
@@ -1 +0,0 @@
1
- # Overview
@@ -1 +0,0 @@
1
- # Config
@@ -1,8 +0,0 @@
1
- # WordPress + Vercel
2
-
3
- WIP
4
-
5
- - `SITE_URL` environment variable in Vercel
6
- - `serverless.endpoints` option in `ed.config.json` — so that:
7
- - Frontend code executed in WordPress can access API endpoints hosted on Vercel
8
- - WordPress can redirect to the Vercel URL if WordPress is being used completely headless
@@ -1 +0,0 @@
1
- # APIs
@@ -1 +0,0 @@
1
- # RPC API
@@ -1,4 +0,0 @@
1
- {
2
- "label": "☀️ Serverless",
3
- "position": 5
4
- }
@@ -1,18 +0,0 @@
1
- ---
2
- sidebar_position: 1
3
- ---
4
-
5
- # WordPress
6
-
7
- There are several CMS' out there, and while WordPress may not be the most modern, it's very well known (both to clients and developers) and is easy to work with and host.
8
-
9
- ## Why not a cloud-based headless CMS + Next.js?
10
-
11
- We use WordPress as a semi-headless CMS. While there are plenty of cloud-based headless CMS' out there, there are several issues with using them:
12
-
13
- - They can be quite expensive!
14
- - They often lack features we require, such as versioning, translation, ecommerce, user registration, user-submitted data, live preview and block-based content editing. These features are also often hidden behind an expensive 'Enterprise' plan.
15
- - The lack of specific features often leads to the requirement of additional third-party platforms, which adds a great deal of complexity to our projects.
16
- - Integrating them with frameworks like Next.js require lots of boilerplate code, which becomes hard to maintain.
17
- - Next.js' file-based routing is great for web apps, but imposes limitations on URL customisation which are hard to overcome.
18
- - We love our elegant page transitions, and these are harder to achive with Next.js.
@@ -1,15 +0,0 @@
1
- ---
2
- sidebar_position: 2
3
- ---
4
-
5
- # Flywheel + Local
6
-
7
- Our primary WordPress hosting provider is [Flywheel](https://getflywheel.com/). We have an organisation plan which allows us to host hundreds of WordPress sites, managed in an easy-to-use [dashboard](https://app.getflywheel.com/).
8
-
9
- [Local](https://localwp.com/) is a desktop app which provides a development environment for WordPress sites, and was developed by Flywheel. It has useful 'sync' functionality, allowing you to push/pull files and the database between Local and a Flywheel site.
10
-
11
- ## Local Sync
12
-
13
- Feel free to use Local Sync to deploy your WordPress site to Flywheel during the initial stages of development, however it's recommended that you use Github Actions to automate code deployment.
14
-
15
- Pulling from Flywheel to Local is also a great way to pull down a site to work on it locally — just don't forget to re-clone the theme folder so that it's correctly linked to Git.
@@ -1,12 +0,0 @@
1
- ---
2
- sidebar_position: 3
3
- ---
4
-
5
- # React
6
-
7
- There's not much to say! React is great. It's particularly great for complex UI.
8
-
9
- Be sure you're across React, hooks and how to use TypeScript with React. You should also probably know how Context works
10
-
11
- - [React Hooks Guide on Smashing Magazine](https://www.smashingmagazine.com/2020/04/react-hooks-api-guide/) — goes over all the core hooks, as well as how to create custom hooks.
12
- - [React & TypeScript: how to type hooks (a complete guide)](https://devtrium.com/posts/react-typescript-how-to-type-hooks) — learn by looking! Lots of examples and tips on how to correctly use hooks with TypeScript.
@@ -1,13 +0,0 @@
1
- ---
2
- sidebar_position: 4
3
- ---
4
-
5
- # TypeScript
6
-
7
- TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. We use TypeScript to write code that is easier to read and understand, although it is not as fast as JavaScript.
8
-
9
- Some resources:
10
-
11
- - [TypeScript — The Basics](https://www.youtube.com/watch?v=ahCwqrYpIuM) (video)
12
- - [TypeScript with React](https://www.notion.so/ed-studio/ED-Stack-2021-Tour-7f50bc455d95403ebdff9a4503a78aee#b15ee6c11d40449e8f18b9ff19301901) (Udemy course)
13
- - [React & TypeScript: how to type hooks (a complete guide)](https://devtrium.com/posts/react-typescript-how-to-type-hooks) — learn by looking! Lots of examples and tips on how to correctly use hooks with TypeScript.
@@ -1,21 +0,0 @@
1
- # (WP)GraphQL
2
-
3
- "GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools." (from the [GraphQL Website](https://graphql.org/)).
4
-
5
- The [WPGraphQL](https://www.wpgraphql.com/) plugin (which is actually installed in the theme with Composer, rather than a plugin), provides a GraphQL API for WordPress.
6
-
7
- ## Schemas
8
-
9
- GraphQL requires a server to be running to serve the queries. The WPGraphQL plugin provides a server that can be accessed at the URL `/graphql`, or via the `graphql()` PHP function.
10
-
11
- The schema is automatically generated for you by the plugin, and makes all WordPress data available to you via queries.
12
-
13
- You can define your own types and fields on the schema using the PHP functions documented on the [WPGraphQL website](https://www.wpgraphql.com/functions/).
14
-
15
- ## Queries
16
-
17
- Queries are written in `.graphql` files, which can be stored in three locations in your code.
18
-
19
- - `blocks/*/*.graphql`, alongside a block's `.tsx` file. Queries in these files will be run automatically by the server when the page is visited, and the data is passed as props to the block component. This allows blocks to query any other data on the site. Blocks can also query ACF fields defined on the block, via the global `block` field, which represents the current block being executed.
20
- - `views/*.graphql`, alongside any View `.tsx` file. Just like blocks, the data is passed to the view's component. They can also use special variables to refer to the current post, or some querystring value.
21
- - `queries/*.graphql`— these queries will have React hooks automatically generated for them, allowing the queries or mutations to be executed on demand by your React code. This is useful for components which need to perform searching/filtering/pagination, handle user data submissions, trigger server-side code etc.
@@ -1,9 +0,0 @@
1
- # `eddev` Library
2
-
3
- ## Purpose
4
-
5
- TBA
6
-
7
- ## Features
8
-
9
- TBA
@@ -1,4 +0,0 @@
1
- {
2
- "label": "📚 The Stack",
3
- "position": 1
4
- }
@@ -1,25 +0,0 @@
1
- # Scripts
2
-
3
- ## `yarn dev`
4
-
5
- The 'dev' command provides hot-reloading for multiple bundles — like frontend, admin and (eventually) serverless.
6
-
7
- It's custom built, and made to be as clean as possible by showing issues relevant to the most recent attempt at a rebuild.
8
-
9
- ### Webpack
10
-
11
- Internally, the system uses [Webpack](https://webpack.js.org/) and [webpack-dev-server](https://webpack.js.org/configuration/dev-server/), along with [react-refresh](https://github.com/pmmmwh/react-refresh-webpack-plugin). Webpack configuration is _not editable_, and is auto-generated by the tool itself. We may swap Webpack out for another tool such as `swc` or `esbuild` at some point in the future for an additional speed boost, and so allowing access to Webpack config could result in compatibility issues.
12
-
13
- For speed, each Webpack bundle runs in a separate worker thread, so that each bundle can compile concurrently, taking advantage of multiple CPU cores.
14
-
15
- ### GraphQL Codegen
16
-
17
- The dev tool also provides realtime GraphQL -> TypeScript generation, by monitoring your project for changes and rebuilding when appropriate. For this, we're using [GraphQL Code Generator](https://www.graphql-code-generator.com/) with a host of custom plugins.
18
-
19
- These files are _only_ generated by the dev tool, and not be the `yarn build` tooling. This only really matters for dynamic queries in the `queries/` folder. To be safe, you should always make sure `yarn dev` runs after editing a `.graphql` file in your project.
20
-
21
- ## `yarn build`
22
-
23
- This produces production builds of the frontend and admin bundles, with tree shaking, minification and code-splitting.
24
-
25
- It also produces a bundle sizing report, in `/dist/frontnend/bundle-report.html` — which you can use to see which dependencies are bloating up your bundle files. If a dependency is too large, consider dynamically importing it instead.
@@ -1,13 +0,0 @@
1
- # Aliases
2
-
3
- There are a few import aliases predefined for you.
4
-
5
- ```
6
- @components/* -> ./components/*
7
- @hooks/* -> ./hooks/*
8
- @utils/* -> ./utils/*
9
- @theme -> ./theme.css.tsx
10
- @queries -> ./hooks/queries.ts
11
- ```
12
-
13
- This just means that you can use absolute paths to import your components and hooks etc, rather than having to use relative paths — making copy/pasting of import statements around your codebase a little bit easier.
@@ -1,13 +0,0 @@
1
- # Defines
2
-
3
- There are a few globally accessible variables which you can access, which are defined via Webpack's `DefinePlugin`
4
-
5
- From [Webpack configuration docs](https://webpack.js.org/plugins/define-plugin/):
6
-
7
- > The `DefinePlugin` replaces variables in your code with other values or expressions at compile time. This can be useful for allowing different behavior between development builds and production builds. If you perform logging in your development build but not in the production build you might use a global constant to determine whether logging takes place. That's where DefinePlugin shines, set it and forget it rules for development and production builds.
8
-
9
- The following variables are available:
10
-
11
- - `process.dev` — `true` or `false`, depending on whether this bundle is targetting at dev mode or not.
12
- - `process.admin` - `true` or `false`, depending on whether this bundle is used for the admin editor (Gutenberg) or on the frontend. Useful for rendering blocks for better editing experience.
13
- - `process.themePath` - The relative URI pointing to the theme directory. Useful for calculating the location of assets. Note that there is NO trailing slash.
@@ -1,14 +0,0 @@
1
- # Config File
2
-
3
- You'll find a `ed.config.json` file in the root of your theme folder. This file is read by both the `eddev` dev and build tool, along with the supporting `eddev-php` library.
4
-
5
- Here are the options:
6
-
7
- - `serverless` — An optional object.
8
- - `enabled` — `true` or `false` — Controls whether serverless node is enabled for this project.
9
- - `uploads` — `"proxy"` or `"remote"`
10
- - `plugins` — `"proxy"` or `"remote"`
11
- - `theme` — `"proxy"`, `"remote"` or `"copy"`
12
- - `devAssets` — an optional array of glob paths or file names, relative to the theme folder, which are necessary for the frontend — this includes `assets/**` by default.
13
-
14
- You can also find the original schema file [here](https://github.com/ed-digital/eddev/blob/main/src/config/config-schema.ts).
@@ -1,4 +0,0 @@
1
- {
2
- "label": "🛠 Tooling",
3
- "position": 2
4
- }
@@ -1,31 +0,0 @@
1
- # Views Overview
2
-
3
- Views represent the different page types of the site. WordPress will choose which view to use based on the URL of the page. If for example, it identifies that the url `/blog/my-first-post` is a "post" object, it'll first look for `views/single-post.tsx`, followed by `views/single.tsx`. If it doesn't find either of those, it'll use `views/_404.tsx`. The naming of view files follows WordPress' [Template Hierarchy](https://developer.wordpress.org/themes/basics/template-hierarchy/).
4
-
5
- Views exist within the `views` directory as `.tsx` files, often with a paired `.graphql` file.
6
-
7
- The standard `views/page.tsx` looks like this:
8
-
9
- ```tsx title="views/page.tsx"
10
- import { Heading } from "@components/atoms/Heading"
11
- import { Container } from "@components/layout/Grid"
12
- import { defineView } from "eddev/views"
13
- import { ContentBlocks } from "eddev"
14
-
15
- export default defineView("page", (props) => {
16
- return (
17
- <Container>
18
- <Heading variant="h1" css={{ pb: "$6" }}>
19
- {props.page?.title}
20
- </Heading>
21
- <ContentBlocks blocks={props.page?.contentBlocks} />
22
- </Container>
23
- )
24
- })
25
- ```
26
-
27
- You'll notice above the following:
28
-
29
- - The file exports a view defined with the `defineView` function, and the first argument passed to it is the name of the view. This MUST be consistent with the name of the file. The general rule is `views/{name}.tsx`. We just care about the name part!
30
- - We're getting some data from props — `props.page.title` and `props.page.contentBlocks`. These are coming from the linked query file (see the next section)
31
- - The code itself is quite lean. It wouldn't be strange to have a more complex file, but in general it's better to move as much code as possible into separate component files. This encourages reusability and makes it easier to maintain.
@@ -1,18 +0,0 @@
1
- # View Queries
2
-
3
- Views typically need to access data about the current page or object, as well as other arbitrary content from the CMS. To do so, create a `.graphql` file with the same name as the `.tsx` file. The GraphQL query will be executed every request, and the data is automatically passed to the view when it is rendered. You never need to handle the loading process yourself!
4
-
5
- To query the current page or post being viewed, use `$postId` as an input variable.
6
-
7
- ```graphql title="views/page.graphql"
8
- query Page($postId: ID!) {
9
- page(id: $postId, idType: DATABASE_ID) {
10
- title
11
- slug
12
- template {
13
- templateName
14
- }
15
- contentBlocks
16
- }
17
- }
18
- ```
@@ -1,36 +0,0 @@
1
- # Content Blocks
2
-
3
- To allow Gutenberg blocks on your page, you'll need to do two things:
4
-
5
- 1. Ensure you've got a `.graphql` file which selects the `contentBlocks` field from the your post type.
6
- 2. Pass the `contentBlocks` field to the `blocks` prop of the `<ContentBlocks />` component.
7
-
8
- The `ContentBlocks` component is much like `InnerBlocks`, except that blocks are passed in as an array, rather than implictly.
9
-
10
- ```graphql title="views/page.graphql"
11
- query Page($postId: ID!) {
12
- page(id: $postId, idType: DATABASE_ID) {
13
- title
14
- slug
15
- template {
16
- templateName
17
- }
18
- contentBlocks
19
- }
20
- }
21
- ```
22
-
23
- ```tsx title="views/page.jsx"
24
- import { Container } from "@components/layout/Grid"
25
- import { defineView } from "eddev/views"
26
- import { ContentBlocks } from "eddev"
27
-
28
- export default defineView("page", (props) => {
29
- return (
30
- <Container>
31
- <h1>{props.title!}</h1>
32
- <ContentBlocks blocks={props.page?.contentBlocks} />
33
- </Container>
34
- )
35
- })
36
- ```
@@ -1,35 +0,0 @@
1
- # 'App' View
2
-
3
- The `views/_app.tsx` view is a special kind of view. It's always rendered, as the wrapper around your entire frontend. It's usually where you'd put your header/footer and other global elements, as well as where you'll load global styles.
4
-
5
- ```tsx
6
- import { PageLoadIndicator } from "@components/generic/PageLoadIndicator"
7
- import { AdminBar } from "eddev"
8
- import { Header } from "@components/site/Header"
9
- import { defineView } from "eddev/views"
10
- import { fontFaceGlobalStyles, frontendGlobalStyles } from "@theme"
11
- import { Footer } from "@components/site/Footer"
12
-
13
- fontFaceGlobalStyles()
14
- frontendGlobalStyles()
15
-
16
- export default defineView("_app", ({ children }) => {
17
- return (
18
- <>
19
- <PageLoadIndicator />
20
- <AdminBar />
21
- <Header />
22
- {children}
23
- <Footer />
24
- </>
25
- )
26
- })
27
- ```
28
-
29
- ## App Query
30
-
31
- You can write an `views/_app.graphql` file, and the result will be available on every page, via the `useAppData()` hook. The result _wont_ be passed in as props, so be sure to use the hook if you need to access it.
32
-
33
- Note that the `_app.graphql` query only runs _once_ — when the user first loads the page.
34
-
35
- This is especially useful for things like menus, which are often used on every page, and should be accessible from anywhere on the first render of the page.
@@ -1,20 +0,0 @@
1
- # Page Templates
2
-
3
- Page templates are special views, which are selectable from the 'Page Template' dropdown in the page editor.
4
-
5
- To create a page template, create a new view in the 'views/templates/' folder. It should export a view created with the `defineView` function, and also needs some special comments at the top of the file to identify it as a page template. Just like regular WordPress PHP templates.
6
-
7
- ```tsx title="views/templates/special.tsx"
8
- /**
9
- * Template Name: Special
10
- */
11
- import { defineView } from "eddev/views"
12
-
13
- export default defineView("templates/special", () => {
14
- return (
15
- <div>
16
- <h1>Special Template!</h1>
17
- </div>
18
- )
19
- })
20
- ```
@@ -1,4 +0,0 @@
1
- {
2
- "label": "📄 Views",
3
- "position": 3
4
- }
@@ -1,119 +0,0 @@
1
- // @ts-check
2
- // Note: type annotations allow type checking and IDEs autocompletion
3
-
4
- const lightCodeTheme = require("prism-react-renderer/themes/github")
5
- const darkCodeTheme = require("prism-react-renderer/themes/dracula")
6
-
7
- /** @type {import('@docusaurus/types').Config} */
8
- const config = {
9
- title: "dev.ed.studio",
10
- tagline: "WordPress + React 2021",
11
- url: "https://devtools.ed.studio",
12
- baseUrl: "/",
13
- onBrokenLinks: "throw",
14
- onBrokenMarkdownLinks: "warn",
15
- noIndex: true,
16
- favicon: "img/favicon.ico",
17
- organizationName: "facebook", // Usually your GitHub org/user name.
18
- projectName: "eddev-docs", // Usually your repo name.
19
-
20
- presets: [
21
- [
22
- "@docusaurus/preset-classic",
23
- /** @type {import('@docusaurus/preset-classic').Options} */
24
- ({
25
- docs: {
26
- sidebarPath: require.resolve("./sidebars.js"),
27
- // Please change this to your repo.
28
- editUrl: "https://github.com/ed-digital/eddev/edit/main/docs/",
29
- },
30
- blog: {
31
- showReadingTime: true,
32
- // Please change this to your repo.
33
- editUrl: "https://github.com/facebook/docusaurus/edit/main/blog/",
34
- },
35
- theme: {
36
- customCss: require.resolve("./src/css/custom.css"),
37
- },
38
- }),
39
- ],
40
- ],
41
-
42
- themeConfig:
43
- /** @type {import('@docusaurus/preset-classic').ThemeConfig} */
44
- ({
45
- navbar: {
46
- title: "Dev Wiki",
47
- logo: {
48
- alt: "ED. Dev Wiki",
49
- srcDark: "img/logo-white.svg",
50
- src: "img/logo-black.svg",
51
- },
52
- items: [
53
- {
54
- type: "doc",
55
- docId: "intro",
56
- position: "left",
57
- label: "Docs",
58
- },
59
- // { to: "/blog", label: "Blog", position: "left" },
60
- {
61
- href: "https://github.com/ed-digital/eddev",
62
- label: "GitHub",
63
- position: "right",
64
- },
65
- ],
66
- },
67
- // footer: {
68
- // style: "dark",
69
- // links: [
70
- // {
71
- // title: "Docs",
72
- // items: [
73
- // {
74
- // label: "Tutorial",
75
- // to: "/docs/intro",
76
- // },
77
- // ],
78
- // },
79
- // {
80
- // title: "Community",
81
- // items: [
82
- // {
83
- // label: "Stack Overflow",
84
- // href: "https://stackoverflow.com/questions/tagged/docusaurus",
85
- // },
86
- // {
87
- // label: "Discord",
88
- // href: "https://discordapp.com/invite/docusaurus",
89
- // },
90
- // {
91
- // label: "Twitter",
92
- // href: "https://twitter.com/docusaurus",
93
- // },
94
- // ],
95
- // },
96
- // {
97
- // title: "More",
98
- // items: [
99
- // {
100
- // label: "Blog",
101
- // to: "/blog",
102
- // },
103
- // {
104
- // label: "GitHub",
105
- // href: "https://github.com/facebook/docusaurus",
106
- // },
107
- // ],
108
- // },
109
- // ],
110
- // copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`,
111
- // },
112
- prism: {
113
- theme: lightCodeTheme,
114
- darkTheme: darkCodeTheme,
115
- },
116
- }),
117
- }
118
-
119
- module.exports = config
@@ -1,40 +0,0 @@
1
- {
2
- "name": "eddev-docs",
3
- "version": "0.0.0",
4
- "private": true,
5
- "scripts": {
6
- "docusaurus": "docusaurus",
7
- "start": "docusaurus start",
8
- "build": "docusaurus build",
9
- "swizzle": "docusaurus swizzle",
10
- "deploy": "docusaurus deploy",
11
- "clear": "docusaurus clear",
12
- "serve": "docusaurus serve",
13
- "write-translations": "docusaurus write-translations",
14
- "write-heading-ids": "docusaurus write-heading-ids"
15
- },
16
- "dependencies": {
17
- "@docusaurus/core": "2.0.0-beta.6",
18
- "@docusaurus/preset-classic": "2.0.0-beta.6",
19
- "@mdx-js/react": "^1.6.21",
20
- "@svgr/webpack": "^5.5.0",
21
- "clsx": "^1.1.1",
22
- "file-loader": "^6.2.0",
23
- "prism-react-renderer": "^1.2.1",
24
- "react": "^17.0.1",
25
- "react-dom": "^17.0.1",
26
- "url-loader": "^4.1.1"
27
- },
28
- "browserslist": {
29
- "production": [
30
- ">0.5%",
31
- "not dead",
32
- "not op_mini all"
33
- ],
34
- "development": [
35
- "last 1 chrome version",
36
- "last 1 firefox version",
37
- "last 1 safari version"
38
- ]
39
- }
40
- }