Chunk Creations

In software development, we often need to check multiple conditions in one step, be it a frontend component or a backend function. In frontend development, it will mostly decide about UI state. Let’s say there are multiple conditions coming from different parts of the system: user permission levels, user subscription plans, entity states, etc. Usually frontend code grows with the complexity of product’s business logic. This often starts as a simple conditional statement like so: import React from 'react' export const App = () => { // authentication logic here const authenticated = useIsAuth() // decide which view to show return authenticated ? : } This is very basic conditional logic for displaying private routes only to authenticated (logged in) users. When things get complicated The previous example was very rudimentary. Complexity can grow very quickly as business requirements grow and evolve in a Scrum environment. It’s highly likely more conditions will be added to the app’s business logic and be required to check for proper UI display. For this let’s use example of Meta’s Messenger app and the single message entity. First, we define a simple Message entity with all its relevant properties and context: type Message = { id: string senderId: string recipientId: string sentAt: Date deliveredAt?: Date seenAt?: Date deleted: boolean failed: boolean attachmentsCount: number isPinned: boolean isEdited: boolean isReply: boolean isGroupMessage: boolean currentUserId: string } Below is a table of conditions that control how the UI behaves for each message:

Visual mapping If isFailedToSend → show red error icon and retry option. If isDelivered but not isSeen → show double-check icon in gray. If isSeen → show double-check icon in blue. If canEdit → show edit button. If showPinnedIcon → display pin in corner. If showReplyPreview → show small reply preview UI. Now let’s see how this could be implemented without any clever refactors—just growing the codebase overtime. import React from 'react' import { Check, DoubleCheck, Pin, WarningTriangle, Attachment, EditPencil, Reply, } from 'iconoir-react' import { Message } from './types' type MessageProps = { message: Message userIsGroupAdmin: boolean }export const OldFlagsMessage: React.FC = ({ message, userIsGroupAdmin, }) => { const isSent = !!message.sentAt && !message.failed const isDelivered = !!message.deliveredAt && !message.seenAt const isSeen = !!message.seenAt const isFailedToSend = message.failed const canEdit = message.senderId === message.currentUserId && !message.deleted && !message.failed return // render From terrible mess to terribly clever The code above is less than ideal, especially around readability. As a first step, one could certainly refactor all those checks into hooks. But let’s go deeper into this refactor, as business requirements will certainly grow, as the only constant in life (and especially in software development) is change. Death and taxes are just a derivative of that. So we want to create a future-proof refactor that could possibly be a more robust solution that, if necessary, could be used in other places of the system. The latter is an especially good requirement because making this a bit more top-level and detached from the very business logic allows sharing responsibility for this code among many team members. Easing code maintenance and benefiting from sharing ideas around this solution. There are few things those conditions have in common: result is a boolean flag they can be isolated—they are not interdependent. they depend on a limited source of truth—deciding data passed to the component is a limited set. All this tells us there is a solution to this problem that could be expressed as function a => (payload: LimitedDataSet) => boolean If we could define all boolean flags as such functions, we could include them in a data set that could run each function with the same payload and collect results for each flag. If this is not clever, then I hate React. So, inspired by eslint rules and cva props evaluation, I created a simple engine that takes an array of rules (not nested) and runs each function with provided props. Each Rule is represented with its name, and the function that returns boolean. The function evaluates the incoming props and returns a boolean value: a Flag. export type Rules< A = any, K extends string | number | symbol = string, > = Record boolean> export type Flags = Record< K, boolean > Modeling these conditions as a rules object With the above pattern, we can create a set of functions—in this case in an object: //basically component props in our case export type MessageRulesArgs = { message: Message userIsGroupAdmin: boolean } // this is definiton of our required flags export type MessageRuleSet = { isSent: boolean isDelivered: boolean isSeen: boolean canEdit: boolean showPinnedIcon: boolean showEditedIndicator: boolean showReplyPreview: boolean showAttachmentIcon: boolean showFailedIcon: boolean showDeleteButton: boolean } export type MessageRules = Rules export const messageRules: MessageRules = { isSent: ({ message: m }) => !!m.sentAt && !m.failed, isDelivered: ({ message: m }) => !!m.deliveredAt && !m.seenAt, isSeen: ({ message: m }) => !!m.seenAt, canEdit: ({ message: m }) => m.senderId === m.currentUserId && !m.deleted && !m.failed, showPinnedIcon: ({ message: m }) => m.isPinned, showEditedIndicator: ({ message: m }) => m.isEdited, showReplyPreview: ({ message: m }) => m.isReply, showAttachmentIcon: ({ message: m }) => m.attachmentsCount > 0, showFailedIcon: ({ message: m }) => m.failed, showDeleteButton: ({ message: m }) => m.senderId === m.currentUserId && !m.deleted, } With rules defined, the remaining thing to do is run and evaluate the result with our data. For this I came up with this little helper: import type { Flags, Rules } from './types' export const applyRules = < A = any, K extends string | number | symbol = string, >( rule: Rules, args: A, ): Flags => { return Object.keys(rule).reduce((flags: Flags, key: string) => { const ruleFn = rule[key as K] if (ruleFn) { flags[key] = ruleFn(args) } return flags }, {}) as Flags } Then, to use it inside a component, we can create a hook: import { useDeepCompareMemo } from 'use-deep-compare' import { applyRules } from './apply-rules' import { Rules } from '../types' export const useRules = < RuleSet extends Rules, Args extends Record, >( rules: RuleSet, args: Args, ): Record => { // use a deep compare memo to memoize the result regardless of depth return useDeepCompareMemo( () => applyRules(rules, args), [rules, args], ) } Final usage in React component: import { Attachment, Check, DoubleCheck, EditPencil, Pin, Reply, WarningTriangle, } from 'iconoir-react' import React from 'react' import { messageRules } from './rules/rules' import { useRules } from './rules/rules-hook' import { Message, MessageRules, MessageRulesArgs } from './types' type MessageProps = { message: Message userIsGroupAdmin: boolean } export const WithRulesMessage: React.FC = ({ message, userIsGroupAdmin, }) => { const { isSent, isDelivered, isSeen, canEdit, showPinnedIcon, showEditedIndicator, showReplyPreview, showAttachmentIcon, showFailedIcon, showDeleteButton, } = useRules(messageRules, { message, userIsGroupAdmin, }) return //render } Benefits of this approach Clarity: Each condition is named and easy to understand. Reusability: Components can import and use conditions without duplication. Testability: Each rule can be unit-tested independently. Extensibility: Adding new rules is simple and low-risk. Conclusion If you find yourself with growing UI complexity and a web of conditions, consider abstracting those checks into a rules object or lightweight engine. It brings structure, clarity, and scalability to what would otherwise become a nightmare of conditionals and spaghetti code. Originally published at https://www.pawelkrystkiewicz.pl on October 3, 2024.

How to create smooth height animations for collapsible content using Framer Motion and dynamic duration calculations based on content size. The Height Animation Problem Animating height transitions is notoriously tricky in CSS. Unlike opacity or transforms, you can’t simply transition from height: 0 to height: auto. The browser needs concrete values to interpolate between: /* This doesn't work */ .collapsible { height: 0; transition: height 0.3s; }.collapsible.open { height: auto; /* Can't animate to 'auto' */ } Common workarounds involve JavaScript to calculate heights, max-height hacks that create awkward timing, or fixed heights that break with dynamic content. None of these are ideal. For expandable sections, accordions, dropdowns, or any collapsible UI, we need smooth height transitions that work with dynamic content of any size. Solution Framer Motion combined with the react-use library's useMeasure hook gives us a clean solution. We measure the content's actual height and animate to that specific value, with smart duration scaling based on content size. import type { FC, ReactNode } from 'react' import { useMeasure } from 'react-use' import { motion } from 'framer-motion' interface AnimateHeightProps { isVisible: boolean ease?: string duration?: number className?: string variants?: { open: object collapsed: object } children: ReactNode }export const AnimateHeight: FC = ({ duration, ease, variants, isVisible, children, ...other }) => { const [ref, { height }] = useMeasure() return (

{children}

) }/** * Get the duration of the animation depending upon * the height provided. * @param {number} height of container */ const getAutoHeightDuration = (height: number) => { if (!height) return 0 const constant = height / 36 return Math.round((4 + 15 * constant ** 0.25 + constant / 5) * 10) }AnimateHeight.defaultProps = { ease: 'easeInOut', variants: { open: { opacity: 1, height: 'auto', }, collapsed: { opacity: 0, height: 0 }, }, } How It Works useMeasure Hook: Tracks the actual rendered height of the content in real-time. When content changes, the height updates automatically. Motion Variants: Define two states: open - Full height with opacity 1 collapsed - Zero height with opacity 0 Dynamic Duration: The getAutoHeightDuration function calculates animation timing based on content height. Taller content gets longer animations, preventing jarring fast transitions for large sections. overflow-hidden: Critical for the effect - hides content as the container shrinks to zero height. inherit=false: Prevents inheriting animation variants from parent motion components, keeping this animation independent. The Duration Formula The getAutoHeightDuration function deserves attention: const getAutoHeightDuration = (height: number) => { if (!height) return 0 const constant = height / 36 return Math.round((4 + 15 * constant ** 0.25 + constant / 5) * 10) } This formula creates a non-linear relationship between height and duration: Small heights (50px): ~150ms Medium heights (200px): ~250ms Large heights (500px): ~400ms Extra large (1000px): ~550ms Breaking Down the Math Let’s dissect that return statement: Math.round((4 + 15 * constant ** 0.25 + constant / 5) * 10) Step 1: Normalize the height const constant = height / 36 This converts pixels to a normalized scale. For example, 360px becomes 10, making the math more manageable. This is totally arbitrary; pick what works best for your use case. Step 2: Three components create the curve The formula has three parts that add together: Base duration: 4 Ensures even tiny elements get at least 40ms (after × 10) 2. Diminishing growth: 15 * constant ** 0.25 The ** 0.25 is a fourth root creates sublinear growth This is the key: doubling height doesn’t double duration Prevents massive elements from having sluggish animations 3. Linear component: constant / 5 Adds some proportional scaling Balances out the diminishing returns from component 2 Step 3: Scale to milliseconds Math.round((...) * 10) Multiply by 10 to convert to milliseconds and round for clean values. Why This Curve? The fourth root (** 0.25) is the secret sauce. Compare linear vs fourth-root scaling: https://medium.com/media/370d5ec67cac76057bbfef0fc0a9dee3/href Without the fourth root, large collapsible sections would take almost a second to animate, feeling slow and unresponsive. The formula keeps animations snappy regardless of content size while still giving taller content enough time to feel smooth. For an extra crispy effect, you could clamp this value to keep it within the desired range. Math.max(Math.min(calculated, 40, 350)) At the end of day, you can override this by passing a fixed duration prop when you need consistent timing across all heights. Practical Usage Simple accordion: const Accordion = ({ title, content }) => { const [isOpen, setIsOpen] = useState(false) return (

{content}

) } Custom animation variants: Fixed duration for consistent timing: {children} Why This Approach Works Automatic measurement: No manual height calculations needed. The component adapts to content changes automatically. Smooth animations: Unlike max-height hacks, the animation duration matches the actual height transition. Flexible: Override defaults when needed while keeping sensible behavior out of the box. Dynamic content friendly: If content height changes while open, the animation adjusts seamlessly. Performance Considerations While this approach is generally performant, be aware: Height animations trigger layout recalculation: Unlike transforms, animating height is not GPU-accelerated. For numerous simultaneous animations, this can impact performance. Measurement overhead: useMeasure uses ResizeObserver, which is efficient but adds overhead. For hundreds of collapsible items, consider virtualization. Alternative for performance-critical cases: If you need many height animations, consider animating scaleY transform instead: // More performant but content gets squished The tradeoff is that scaleY squishes content during animation, while height animations maintain readable content throughout. Comparison with AnimatePresence This component differs from the AnimateAppearance pattern: https://medium.com/media/4984edf8d13dab938e97f362dc07fb73/href Use AnimateHeight when content should remain in the DOM (for SEO, form state, etc.) and you want vertical expand/collapse. Use AnimatePresence when components are truly conditional and should be unmounted. Common Use Cases FAQ accordions: { faqs.map(faq => ( {faq.answer} )) } Filter panels: Form sections: Conclusion The AnimateHeight component solves one of CSS's most annoying limitations by combining Framer Motion's animation capabilities with real-time height measurement. By automating the measurement and providing smart duration scaling, we get: Smooth height transitions without CSS hacks Automatic adaptation to dynamic content Customizable timing when needed Clean, reusable animation logic Next time you need a collapsible section, skip the CSS gymnastics and reach for this component. Your users will appreciate the smooth, professional transitions. Originally published at https://www.pawelkrystkiewicz.pl on February 10, 2024.

Articles

Lessons Learned: NPM packages publishing and API authorization

Tailwind 4 Dark Mode Dynamic Theme

Building a Smart Truncation Detection Hook for React

Managing UI Decision Complexity—From Boolean Soup to Business Rules

Framer Motion: Animating Height Transitions in React

The Magic of Bookmarklets