React Compound Components, PostgreSQL 19 SQL Graph Queries, and AI Design Skills
Published on 17.06.2026
You're Using React Compound Components Wrong
TLDR: The compound component pattern in React is more nuanced than most tutorials show. Getting it wrong leads to brittle APIs that leak implementation details to consumers.
Summary: Compound components are one of those patterns that looks simple on the surface but hides a lot of subtlety. The basic idea is grouping related components under a shared parent so they can implicitly share state without prop drilling. Think of how a native HTML select element works with its option children. You don't pass selectedIndex down to each option. The parent owns the state and the children respond to it. That's the spirit of the pattern.
The mistake most developers make is over-relying on React context for the communication layer without thinking through the component boundary design. Context is the right tool but the way you structure what goes into context, and more importantly what stays out of it, determines whether your compound component API is pleasant or painful. When you dump too much into the shared context you end up with re-renders that ripple across all children whenever anything changes.
The deeper issue is API design for component libraries. Compound components are a way of creating controlled, composable APIs that feel natural at the call site. The parent handles orchestration. The children declare intent. Done well, consumers can mix and match children in ways you never anticipated. Done poorly, every new use case requires changes to the internal structure, and you've just built a more complicated version of a giant monolith component with a deceptively clean exterior.
I keep thinking about how this pattern really shines when you have genuinely independent child components that share a behavioral contract with the parent, not just visual grouping. If you find yourself with five child components that all just render differently but have no real state interaction, a simple layout component with children props would serve you better.
Key takeaways:
- Compound components work best when children need to respond to shared state, not just shared styling
- React context powers implicit communication between parent and children, but scope it carefully to avoid unnecessary re-renders
- The pattern's real value is composable APIs at the call site, which requires thinking from the consumer's perspective first
Why do I care: I've reviewed enough component library code to know this pattern is widely misunderstood. The test I apply is: can a consumer use only two of the five child components and get a coherent result? If the answer is no, it's probably not a real compound component, it's just a tightly coupled component tree wearing a pattern as a costume. The article is a good reminder to be intentional about what "compound" actually means.
You're Using React Compound Components Wrong
PostgreSQL 19 Beta Introduces SQL Graph Queries and Concurrent Table Repacking
TLDR: PostgreSQL 19 adds native SQL/PGQ syntax for graph queries, letting you traverse connected data without extensions or external graph databases. Concurrent table repacking means you no longer need full table locks for table reorganization.
Summary: Graph queries have been a persistent gap in relational databases. The standard workaround is a recursive common table expression, which works but is not particularly readable and can be slow on large datasets without careful index design. SQL/PGQ, which is part of the SQL:2023 standard, gives you a proper GRAPH_TABLE construct with pattern matching syntax. You describe the path you want to traverse, nodes and edges, and the query planner figures out the execution. This is a big deal for anyone modeling relationships like org charts, network topologies, or recommendation graphs without wanting to run a separate Neo4j instance.
The concurrent table repacking feature solves a different but very real operational pain point. Repacking a table in PostgreSQL, whether you are adding a column with a non-null default, changing column types, or just reclaiming bloat, has historically required an exclusive lock. On a high-traffic production database that can mean either a maintenance window or accepting that the operation will block for a long time. Concurrent repacking builds the new table structure in the background and swaps it in with a brief final lock, similar to how online schema changes work in MySQL with tools like gh-ost.
What is not mentioned in the announcement is what the graph query performance story looks like against purpose-built graph databases. SQL/PGQ in PostgreSQL is going to be relational storage with graph query syntax on top. For highly connected data with many hops and complex traversal patterns, a native graph store like Neo4j still has structural advantages. PostgreSQL's strength here is reducing the operational cost of the two-database setup for use cases that are mostly relational with occasional graph traversals.
The concurrent repacking is the change I am more excited about in practice. Schema migrations on large tables have been a source of production incidents since forever, and anything that reduces the blast radius of a migration is worth celebrating.
Key takeaways:
- PostgreSQL 19 adds SQL/PGQ graph query syntax for traversing relationships without recursive CTEs
- Concurrent table repacking eliminates the need for full exclusive locks during table reorganization
- Graph query performance compared to native graph databases remains an open question worth benchmarking for your specific workload
Why do I care: I have had to architect "relational-plus-graph" systems before and the operational overhead of keeping two database systems in sync is significant. If PostgreSQL's graph queries perform well enough for moderate-depth traversals, that is one fewer infrastructure component for a lot of teams. The concurrent repacking is the kind of unsexy feature that prevents 2am incidents, and I appreciate the PostgreSQL team prioritizing it.
PostgreSQL 19 Beta Introduces SQL Graph Queries and Concurrent Table Repacking
UI Skills: A Design-Engineering Collection for Humans and Agents
TLDR: UI Skills is a curated library of design-engineering techniques aimed at both human developers and AI agents building interfaces. The goal is bridging the gap between visual design intent and correct implementation.
Summary: There is a real problem at the intersection of design and engineering that gets worse as AI agents enter the picture. Designers think in terms of visual outcomes, spacing systems, and interaction states. Engineers think in terms of component APIs, state machines, and constraint systems. AI agents, when asked to build UI, tend to pattern-match to the most common examples in their training data, which often means generic, low-quality interfaces that technically render but feel wrong.
UI Skills tries to codify the tacit knowledge that experienced design engineers carry around. Things like how to handle focus states in a way that is both accessible and visually coherent, how to implement motion that respects user preferences, or how to structure component variants so they compose cleanly. This is the kind of knowledge that is usually transmitted through code review and pair programming, not documentation.
The interesting bet here is that making these skills explicit and machine-readable could improve what AI coding agents produce. If an agent has a structured understanding of how to correctly implement a disclosure widget or a combobox, rather than just having seen many examples, the outputs could be more reliable. That is worth watching.
What I'd push back on is the assumption that formalizing design-engineering knowledge is sufficient to close the gap. A lot of what makes an interface feel right is contextual judgment that is hard to encode. Knowing the pattern for a skip-to-content link is different from knowing when to use it, where to place it, and how to style it for a specific design system. The library is a good start but the hard problem remains.
Key takeaways:
- UI Skills encodes design-engineering patterns as machine-readable knowledge for both human and AI developers
- The project addresses the gap between design intent and technically correct implementation
- Formalizing tacit design knowledge is valuable but contextual judgment still requires human input
Why do I care: I spend time reviewing AI-generated UI code and the quality variance is enormous. Anything that gives agents better priors for interface implementation is worth investing in. The design-engineering overlap is also a career path that more frontend developers should pursue. The people who can fluently translate between visual and technical are disproportionately valuable on any product team.