- Bleeding edge of technology update#
- Bleeding edge of technology upgrade#
- Bleeding edge of technology full#
Attempting to get a handle on requests and bug reports, you introduce a review process for using the new system but it becomes known as another barrier to shipping. Things are slipping through the cracks where the new world is meeting the old and you stop spending time rewriting old code and spend more time repairing new cracks. Individually these aren’t big problems but it feels like new requests and bugs are cropping up every day.
Bleeding edge of technology full#
You’re asked to prepare a full day workshop on React hooks to the rest of the engineering team who have never used them before. A new team wants to use the GraphQL API to prototype a new analytics tool - but you’ve only converted two endpoints. It starts with a designer wanting one of the shiny new Chakra buttons on one of the old pages - but the font size is all wrong. You’re confident that as long as everyone can switch to doing everything the new way, the old way of doing things will wither and die out.īut soon the cracks begin to show. You’re praised for how much easier the code is to review and how much better it looks. You tackle a couple of pages and find the results wonderful. You spend hours setting up storybook for documentation on a custom domain. Chakra solves all our global styling conflicts while providing accessible, themeable markup that our designers love. React hooks simplifies local state management and cuts component length down to size. GraphQL works beautifully with the Apollo client and we get global state management for free. From now on all endpoints will be written in GraphQL and self-documented with GraphiQL. You decide to make a clean break and adopt the bleeding edge technologies of the day. Global styles are messing with the chat widget and everyone complains about the endless Redux “boilerplate”. It’s impossible to know whether a JSON endpoint returns nested objects or a single resource. There are over 200 components with some that are over 300 lines long. It’s definitely starting to show its age. These technologies were adopted five years ago when the company moved from server-rendered views to a single page application. We’re currently working with a React codebase that uses a JSON API for talking to the server, Redux for managing global state, React component classes for managing local state and Sass classes for styling elements. Let’s imagine we’ve been given the go-ahead to make some changes to a legacy front-end codebase. I hope it might help you avoid the common pitfalls I’ve seen and suffered in my ten years of working in tech.
Bleeding edge of technology upgrade#
I’d like to share the model I use for breaking down front-end upgrade projects.
Bleeding edge of technology update#
Continuous improvement is a core tenet of modern online product development and it’s in everyone’s best interest to replace and update software with better technologies as they become available. These technologies often represent big wins for engineers, businesses and customers - boasting huge gains in usability, reliability and performance. If you’re anything like me you know it can be simultaneously exciting and depressing when a better way of building UIs, managing state or talking to servers does the rounds on Twitter or skyrockets in GitHub stars.
As a Senior Engineer at UsabilityHub, I try to keep on top of the progress in front-end technology as best I can.
0 kommentar(er)
