4 ms·
To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with
by umvi 4y ago
To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with some extra features we wanted. Swagger UI 3.0+ was completely rewritten in React, and I had a super hard time navigating the new source code and trying to figure out how to achieve the same basic things I did with 2.0 with some minor JS tweaks. I'm sure if I invested a few days/weeks becoming a React expert I would be able to do it. But I wasn't willing to do that, so as a result, we are still on Swagger UI 2.0.
Judge for yourself:
Swagger UI 2.0: https://github.com/swagger-api/swagger-ui/tree/2.x https://github.com/swagger-api/swagger-ui/tree/2.x
vs
Swagger UI 4.0 https://github.com/swagger-api/swagger-ui https://github.com/swagger-api/swagger-ui
- schwartzworld 4y agoI finally got to look at the source code. There's a lot going on, and it's pretty well organized into components and small files. The worst thing is the flat file structure. Diving into a React codebase definitely requires some process and familiarity with dev tools, common patterns and React in general, but the upside is that the process is repeatable. Doesn't do you a lot of good for diving into a random codebase, but as a pro React dev, I can hit the ground running much faster than with a project of similar complexity.