Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
"Expiration Date" feature for Community Hero and Events (#1281)
* Skip rendering events if none are in the future.
* Add moment.js to dependencies and run yarn upgrade
Gatsby already depends on moment, this just lets us use it in our code. This
branch uses it to work with expiry dates.
The yarn upgrade just affects yarn.lock, any pinned packages (like the image
ones we need for caching to work) are left alone.
* Add support for community page expiration dates
The hero and events in `community` now accept an optional `expires` field, which
stops the item in question from rendering when the site is built past that date.
This is done through a new shared expiration helper and its child function
`isExpired`, which uses the `moment` library that Gatsby already depends on to
determine if an arbitrary content object is expired.
Any object with a `date` and/or `expires` key that can be parsed by `moment` is
usable in `isExpired`. Objects without an `expires` will be treated as if they
have an `expires` 7 days after their `date`; this is configurable in a constant.
Also, the expiration helper is in ES5 so it can be used on both during the build
and at runtime.
* Add an expiration date to the current Hero data
* new header
* Create Community/Events and JsonFile models
These enable data previously imported from JSON files to run through
the Gatsby GraphQL interface, allowing us to do arbitrary transformations
and queries of this data.
Building on top of these models allows for more complex features to be
built either on top or in place of the previously imported JSON files.
This is used in expiration dates to do all date parsing and comparisons
at build time, allowing us to query for non-expired events in whatever order
we want (including the original source order) in either direction.
The JsonFiles model differs from `gatsby-source-json` by taking the approach of
simply exposing parsed JSON content to other models to consume instead of
inferring a node schema. It's particularly useful for our large JSON files, but
also simpler to adapt to the possibility of us breaking those files up or even
getting the data from another source. It actually came from one of my personal
branches where I make the sidebar run on this logic, but that ended up being
unnecessary without a feature to justify the change. It will likely be reused in
the sidebar overhaul.
The Community model will handle parsing the community JSON data and reading it
into GraphQL. This becomes much easier by moving the `data.json` from the
`Community` component into the `content` folder. I know we value co-location,
but co-locating this file would mean pointing `gatsby-source-filesystem` at our
entire source folder. It makes a lot of sense for this to be in `content` as
well.
This also changes the expiration helpers, splitting the old
`isExpired({date,expires})` into `getExpirationDate({date,expires})` and
`isExpired(expires)`. This allows consumers to get the exact expiration date as
well as be able to use a boolean.
The new expiration helpers also consider `expires=false` to mean the given
object never expires. These objects will return `false` when given to
`getExpirationDate` and `isExpired` will immediately return `false` when given
`false`. Since the result of both helpers are added to the GraphQL node, these
implementation details may never come up.
* white background header
* skinny header
* Move Community data into GraphQL
This allows for better build-time processing, enabling things like
build-time querying for non-expired Events and Heroes.
Instead of importing the JSON file directly, Community content data is now
accessed through a custom React hook that wraps `useStaticQuery` and massages
the data into a more usable form.
Events and Heroes are given custom node types, and everything else in the
community json file is carried over in a unique "rest" node that exposes the
rest of the properties in JSON.
The Hero and Event components on the community page are adapted to the new
custom nodes, and the other Community components are successfully working
through the Rest node- they can be truly ported later or left as-is if they
don't need to change.
* Change Community Hero link to fragment
- url changed to `#subscribe` fragment in `data.json`
- hard-coded `target="_blank"` removed from component
- `scroll-behavior: smooth` added to Page base CSS so Fragment links
smooth-scroll.
* mobile banner skinny
* Add Hero from the header branch as a non-expiring fallback.
This also includes the fixes to `target`. This should be handled in the `Link`
wrapper, so we don't have to hard-code it in the Hero component.
* remove border on mobile
* no border for real
* update user generated content links
* update ambassador link
* Create, export, and import interfaces to fix TS issues
This outfits the `useCommunityData` hook with TS definitions which allow it to
pass `yarn ts-lint`. I'm sure they'll have to be changed in the future, but now
that we have them refactoring will be less of an issue.
* Revert global CSS smooth scrolling
* Change DVC Ambassador link to root-relative _self
* Delete banner-mobile.png
* Delete banner.png
* Delete fowler_icon.ico
* Delete ml-axis-of-change.png
* Delete donuts.png
* Add smooth scrolling to local fragment Hero
* Fix TS issues
* Remove duration option which broke animation
I'm probably just using it wrong.
* Change false string to literal false in community.json
* Improve and fix schema
- Add a GraphQL type definition for Hero entries
- Make expiration date helpers safer for Gatsby schema,
as that's the only place they're used.
* move marcel pic
* Integrate smooth scroll into regular link component
Instead of a separate component, the Link component now accepts a
`scrollOptions` object that passes options to the internal local fragment scroll
handler.
This means you can provide a `scrollOptions` object to a link to affect its
scrolling behavior, and this is compatible with links that could be of any type
as the `scrollOptions` object is only read when the `Link` wrapper detects a
local fragment.
This commit also removes special `Link` behavior/imports from the `Hero`
component.
* Rename default banner images to a more generic name
* remove unused import from community model
* Fix unrelated unused imports
These were reported by `yarn ts-lint`, and this commit cleans all warnings from
the output.
* Fix handling of 0 usable events
- Remove test `expires: false`
- Make hook return null if there are no events, but a padded 3-length array in
any other case.
- Fix oversight where `expires` Moment wasn't being converted to `Date` for
Gatsby.
* fix TS issues
* Fix link in community JSON data
There was a duplicate link before that was not only wrong, but caused a
duplicate key issue because we currently use the URL as the key for user blog
post entries.
* Remove TODO
We don't do this here, whoops!
* Change "Women in San Diego" event date
* Display a message in a situation with no events.
* Simplify getExpirationDate
* Explicitly define sourceIndex on Hero items
* Change events placeholder to use a common "gray text" class
I couldn't quickly find any existing class to compose over, so I made one in the
main Community module.
* Write tests for Expiration helpers
* Fix a typo in Event css
* Change shared gray text class to be named "gray"
This avoids a css lint issue, and arguably makes more sense.
Co-authored-by: Elle <[email protected]>- Loading branch information
1 parent
dc0cb53
commit 5e5a993