Yes, I firmly believe that microfrontend is a game-changer in Web development. Microfrontend enables the independence of development and deployment of Web apps while maintaining a fast, cohesive user experience.
A large web app/site is typically divided into several sub-apps based on the URL path. For example, site.com/home and site.com/marketing are two separate apps. Each app maintains its own tech stack, from server to frontend.
Accordingly, Teams are organized to manage the two apps separately.
The reason for this architecture is to reduce dependency. By dividing the large site into two sub-apps, teams can manage their own development and deployment…
Although React and other Web frameworks make it easier to share components, sharing doesn’t happen by default. Challenges still exist, especially at an enterprise level, which demands extra efforts to coordinate among teams working on various products across organizations. In reality, even discovering components created by other teams is hard.
We would like to share how we reuse components at PayPal. While we are not readily sharing our solution codebase, we are eager to share our thoughts behind it. In particular, we try to address these problems:
A great advantage of GraphQL is you can colocate GraphQL query with React components. For example,
Here in the component we get data from GraphQL query (using Apollo query hook), and are immediately able to render it. It is sweet because it is clear what data the component requires from server and how the component renders the data. Colocating the logics makes it much easier to understand and debug the code.
Data fetching takes time, and we usually want to show users some loading indicator before we can render the data. That’s why the query hook also returns a…
When I first heard JAMstack, or “static app” over a year ago, I was confused. What does it mean to be “static”? Does it take “dynamic” server data and “dynamic” user input? I made my biggest courage and threw our these questions in our internal slack channel. Our then architect Jamund Ferguson kindly helped clarify:
CSS is not fun to me personally. But the css-in-js solution provided by tools like
styled-components makes it a lot more fun as I feel I am developing a react component with all props available beyond simply css.
I like both
styled-component. Albeit that they implement in different mechanisms under the hood and thus their size and performance differ, the exposed API and developer experience is very similar. They would be my "go-to" solution for styling a component.
…until I came across Theme UI recently.
Is this yet another css-in-js solution?
Not really. Theme UI is…
Most people today use modern browsers, yet we still have a small but important percentage of traffic from legacy browsers like Internet Explorer.
There are two things modern browsers can do but legacy browsers cannot. First, modern browsers support many new syntax offered in ES2015+, such as ES module
import, arrow function, object destructuring, etc. For legacy browsers, these new syntax must be transpiled to compatible forms, usually with Babel.
Second, modern browsers support many newer ES2015+ functions, such as Promise, fetch,
Array.proptype.includes. For these functions to work in legacy browsers, the corresponding polyfills must be provided.
To ensure our…
If you find this post useful, don’t forget to give me your 👏 (s) and follow me on twitter https://twitter.com/imDongCHEN
If the same module is listed both as a dependency of an application and one of its dependencies’ dependency, but their listed version is different, how would npm handle the case? That is, we have a dependency tree like:
These four tips are lessons I learned recently. Just want to share in case you find it useful.
When a component is only rendered in some condition, you can either do conditional rendering
Or use class name /css to toggle hiding of the component
Usually we should use conditional rendering. It is faster because no component is generated and thus React does not need to do rendering / reconcilation / DOM operation. In contrast, in the css approach, React still needs to create the DOM and do all the updating even though it’s never shown.
Another benefit of…
This post discusses a usage pattern of middleware in Node.js, and my thoughts on its pros and cons. I’ll start with a brief introduction to the concept of middleware. If you are familiar with middleware, you can jump to [Con of middleware]
Ideally, building an app should be like building lego. Each component is a piece of functionality and we just compose them together. However, it is actually not that straightforward as we have more things to take care of. For example, we must implement the API exposed by each component, including the event handlers, and props needed. We also probably need to maintain an internal state, update the state in event handlers, and map state to corresponding component props. How should we share these codes when we try to compose components?
Web engineer @robinhood; PhD in Human-Computer Interaction