Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions scripts/sync-sched/schedule-2025.json
Original file line number Diff line number Diff line change
Expand Up @@ -2467,7 +2467,7 @@
"event_end": "2025-09-09 11:25",
"event_type": "Developer Experience",
"description": "GraphQL error handling sucks. There, I said it.\n\nEver hunted through the errors list to figure out if a null was legit or caused by an error? If you're like me, you gave up and now treat nulls as \"maybe errored, maybe absent, maybe both.\"\n\nAnd nullability. Schema designers make anything that might fail nullable, producing partial responses when errors occur. But since anything can fail, now everything is nullable—\nand we're drowning in null checks. We recklessly cast to non-null or fall back to the empty string out of desperation. And we still don't know what's truly nullable.\n\nNo more.\n\nThis talk introduces a new, pragmatic approach, born from years of work by the Nullability WG. We propose a future where schemas reflect the true nullability of business entities, and error handling is where it belongs: in your code, not your data. Use your language's built-in tools to handle errors ergonomically; and drop the unnecessary null checks. When you read a null, it should mean one thing: the absence of data.\n\nThis isn't some distant ideal on the horizon of GraphQL's future; with just 512 bytes added to your GraphQL client, you can start adopting this today. Come see how.",
"goers": "13",
"goers": "12",
"seats": "0",
"invite_only": "N",
"venue": "IJzaal - 5th Floor",
Expand Down Expand Up @@ -2513,7 +2513,7 @@
"event_end": "2025-09-09 12:15",
"event_type": "Unconference",
"description": "Lightning Talks: <ul><li> Samuel Vazquez - MCP server demo </li><li> Andres Ortiz - GraphQL + Neo4j graph database demo </li><li> Giuseppe Abrignani - GraphQL / Enterprise data modell </li><li> Lars de Bruijn - Quantifying graphQL Schema Health </li><li> Lars de Bruijn - Trusted Documents </li></ul> <a href=\"https://github.com/graphql/graphql-wg/discussions/1815\" rel=\"noopener noreferrer\" target=\"_blank\">Lightning Talk submissions & discussion thread\n</a>\n***\n\"Unconference\" starts with U! Do you have a demo to share, an itch to scratch, lightning talk to workshop, or proposal you want to brainstorm? There's ample opportunity to bring your thoughts to the unconference table and seek or share feedback.\n\nThe unconference agenda will be created onsite - stay tuned for more info about how you can add your topics.",
"goers": "0",
"goers": "1",
"seats": "0",
"invite_only": "N",
"venue": "Studio - 5th Floor",
Expand Down Expand Up @@ -2609,7 +2609,7 @@
"event_end": "2025-09-09 12:15",
"event_type": "GraphQL Working Group",
"description": "Although the topic of namespacing has been brought up repeatedly in the GraphQL community over the last decade, there is an understandable worry that it would lead to anti-patterns in schema design. If namespacing is used as an excuse to avoid coordination between teams, this can result in a fragmented GraphQL schema that reflects current team boundaries as opposed to domain or client concerns.\n\nGraphQL Federation offers an alternative architecture: when coordination is enforced and consistency guaranteed, a large number of teams can contribute to a single, coherent GraphQL schema without the danger of stepping on each other's toes.\n\nEven with that architecture in place however, I believe there are still legitimate use cases for namespacing. In this talk, I will go over some of those use cases, and formulate a set of design principles that could guide the introduction of namespacing in GraphQL.",
"goers": "14",
"goers": "13",
"seats": "0",
"invite_only": "N",
"venue": "IJzaal - 5th Floor",
Expand Down
40 changes: 20 additions & 20 deletions scripts/sync-sched/speakers.json
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371311
},
{
"username": "adam.sayah",
Expand Down Expand Up @@ -212,7 +212,7 @@
2023,
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371311
},
{
"username": "alex_reilly.7ldur4l",
Expand Down Expand Up @@ -350,7 +350,7 @@
2024,
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371311
},
{
"username": "andrei.bocan",
Expand All @@ -366,7 +366,7 @@
2024,
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371311
},
{
"username": "andrew.doyle1",
Expand Down Expand Up @@ -528,7 +528,7 @@
2023,
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371311
},
{
"username": "arkenflame",
Expand Down Expand Up @@ -590,7 +590,7 @@
2024,
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371312
},
{
"username": "benjamin154",
Expand Down Expand Up @@ -631,7 +631,7 @@
2024,
2025
],
"~syncedDetailsAt": 1757085026624
"~syncedDetailsAt": 1757407371312
},
{
"username": "BoD",
Expand Down Expand Up @@ -780,7 +780,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757085026624
"~syncedDetailsAt": 1757407371312
},
{
"username": "christian.ernst",
Expand Down Expand Up @@ -820,7 +820,7 @@
2024,
2025
],
"~syncedDetailsAt": 1757085026624
"~syncedDetailsAt": 1757407371312
},
{
"username": "christian.stangier",
Expand Down Expand Up @@ -954,7 +954,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757085026624
"~syncedDetailsAt": 1757407462891
},
{
"username": "donnasiqizhou",
Expand All @@ -975,7 +975,7 @@
2023,
2025
],
"~syncedDetailsAt": 1757085026625
"~syncedDetailsAt": 1757407462891
},
{
"username": "dotan1",
Expand All @@ -999,7 +999,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757085026625
"~syncedDetailsAt": 1757407462891
},
{
"username": "dotansimha",
Expand Down Expand Up @@ -1043,7 +1043,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757085026624
"~syncedDetailsAt": 1757407462891
},
{
"username": "eitan15",
Expand Down Expand Up @@ -1132,7 +1132,7 @@
2024,
2025
],
"~syncedDetailsAt": 1757085026625
"~syncedDetailsAt": 1757407462891
},
{
"username": "ernie.turner1",
Expand Down Expand Up @@ -1195,7 +1195,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757085026625
"~syncedDetailsAt": 1757407462891
},
{
"username": "fionabronwen",
Expand All @@ -1215,7 +1215,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757085026625
"~syncedDetailsAt": 1757407462891
},
{
"username": "gabe210",
Expand Down Expand Up @@ -1417,7 +1417,7 @@
2024,
2025
],
"~syncedDetailsAt": 1757102430680
"~syncedDetailsAt": 1757407462891
},
{
"username": "ivan.goncharov.ua",
Expand Down Expand Up @@ -1531,7 +1531,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1757102430680
"~syncedDetailsAt": 1757407462891
},
{
"username": "jeff.auriemma",
Expand All @@ -1557,7 +1557,7 @@
2024,
2025
],
"~syncedDetailsAt": 1757102430680
"~syncedDetailsAt": 1757407462891
},
{
"username": "jeff737",
Expand Down Expand Up @@ -3197,7 +3197,7 @@
"_years": [
2025
],
"~syncedDetailsAt": 1756904606430
"~syncedDetailsAt": 1757407371312
},
{
"username": "tristan119",
Expand Down
15 changes: 9 additions & 6 deletions src/app/conf/_design-system/anchor.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -28,12 +28,15 @@ export const Anchor = forwardRef(function Anchor(
) : (
<a
ref={ref}
{...(!props.href.startsWith("#")
? {
rel: "noopener noreferrer",
target: "_blank",
}
: {})}
{
// we want to show an error if developer doesn't pass a href, but there are cases where it may happen with data from Sched
...(((props.href as string | undefined) || "").startsWith("#")
? {
rel: "noopener noreferrer",
target: "_blank",
}
: {})
}
{...props}
/>
)
Expand Down