# Using Context to Simplify a VERY Large React Form

DevFeed: [Using Context to Simplify a VERY Large React Form](<https://devfeed.tech/articles/using-context-to-simplify-a-very-large-react-form-19158.md>)

Original publisher: [Read original article](<https://artsy.github.io/blog/2022/02/01/using-context-to-simplify-a-react-form/>)

Published: 2022-02-01T00:00:00Z

Content type: article

Language: en

Sources: [Artsy](<https://devfeed.tech/sources/artsy.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Tech Debt](<https://devfeed.tech/topics/tech-debt.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [context](<https://devfeed.tech/tags/context.md>), [developer](<https://devfeed.tech/tags/developer.md>), [react](<https://devfeed.tech/tags/react.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [tech-debt](<https://devfeed.tech/tags/tech-debt.md>), [typescript](<https://devfeed.tech/tags/typescript.md>)

## AI overview

Artsy describes the incremental refactoring and ongoing maintenance of its large Artwork Form, which evolved from Ruby and Haml through JavaScript, jQuery, and React. The article discusses the tradeoffs involved in addressing legacy code and technical debt, including developer experience, user experience, release lead time, and stakeholder support.

## Source excerpt

For those unfamiliar, Artsy is a fine art marketplace. Knowing that, it follows logically to say that the form via which our partners list artworks for sale is an integral part of Artsy's core systems. This form, known only as "The Artwork Form," is whispered about in the halls of Arty's New York headquarters. It is legendary. It is a colossus. It is old enough not only to predate React v16.8 hooks and context APIs, but Artsy's use of React entirely. The first version of the Artwork Form was built in 2014 using ruby and haml, and began its refactoring into JS/JQuery/React a full 2 years later, after having expanded considerably from the original implementation. That process (at least what we've gleaned from our git excavation) was incremental, experimental, and passed through many hands before it landed in the lap of the current Partner Experience (PX) team. PX has since been tasked with the maintenance of this unwieldy kaiju, spending endless amounts of time on seemingly insignificant changes to behavior or UI, all while watching its performance degrade. Many of the people reading this are already familiar with the story we're telling. Many have worked in their very own version of the tale, and borne witness to the fact that legacy code of this scale becomes a living, breathing entity. The developers that tend these beasts learn their patterns and idiosyncrasies, their little moans and groans, and for the sake of expediency work within those constraints to accomplish their tasks. But when is enough, enough? When does the developer time expended working within the constraints of an obsolete design begin to outweigh the time it would take to simply fix the code? First, let's be honest: there is no single right answer to this question. When working in software development we have to deal with certain realities: user experience vs. developer experience, lead time to the next release, buy-in from stakeholders, etc. These factors may weigh more or less depending on the s