This project was bootstrapped with Create React App.
Run yarn install
to install node_modules.
Run yarn start
to start dev-server OR run yarn build
+ serve -s ./build
(or any other static server) to start production build.
Application is divided into the following libs (./src/libs/
):
collection
- feature library for displaying images.core
- shareable core library for utils, configs and types.design-system
- shareable components/styles library for visual elements.layout
- ui library for the application layout.
core
- models, business-logic.data-access
- API, store.shell
- entry point with container.ui
- dummy ui components.
- API is missing flags indicating if the current user liked/commented on an item.
- Links to owner avatars (
ownerImage
) are broken (403 error), so as a work-around I replaced them with random avatars from randomuser.me (checksrc/libs/collection/data-access/map-collection-item.ts
). - Store is currently implemented using
useReducer
, but could be easily replaced withredux
(or any other global state management library), once the state would need to become global. - Masonry grid is implemented using
masonic
.react-window
doesn't work in a strict-mode as it relies on deprecatedfindDOMNode
react api.react-virtualized
doesn't support masonry layout. Need to perform extensive performance testing formasonic
library and if bottle-necks are revealed - consider extracting image size on the back-end side and implementing custom virtualized masonry grid.
- Consider replacing px with rem (font-sizes, spaces) - that would ease UI scaling.
- I tried to extract spacings from figma prototype, but they are inconsistent, so I used the following steps: 4, 8, 12, 16, 24, 32 and use them instead of hard-coded values.
- Consider applying shadow to the top menu when scrolled.
- Consider adding placeholders to avatars and images while they are loading.
- Application shell - 1h
- Grid
- Virtualized grid with various height - 3h (main risk)
- Card - 1h
- Filtration - 1h
- Tests - 1h (for demo only)
Total: 7h
- Application shell - 1h
- Grid
- Virtualized grid with various height - 4h
- Card - 1h
- Filtration - 1h
- Tests - Not implemented.
Total: 7h
What technologies would you use to build the application?
- Core: React
- Grid virtualization: masonic
- Tools: CRA, TypeScript, ESlint, Prettier, Jest, Cypress
What requirements would you have for selecting this technology?
- Requirements for performance and supported platforms (Mobile devices / SSR).
- Team member's competencies with selected technologies.
- Control over 3rd party dependencies (keep the number of dependencies reasonably low to maintain the balance between control and speed of development).
- Ability to scale if needed.
What consideration would you take building the application?
- List of supported browsers, devices, screen resolutions -> Assume that only ever-green browsers are supported, only desktops are supported (but with multiple breakpoints). In real-world app need to make research on the target audience.
- Amount of data -> Assume that pagination is not required, filtering will be performed on the UI side. In real-world app need to introduce server-side filtering and pagination.
- Supported locales/languages -> Assume that only 1 locale/language is supported. In real-world app need to introduce i18n.
- Accessibility -> Assume that a11y is not required. In real-world app need to support a11y.
- Animations -> Assume that animations are not required. In real-world app need to introduce re-flow and loading animations.
- Design System / Colour Palette / Storybook -> Assume that the design system will be introduced later.
- Authentication and Authorization -> Assume that Authentication and Authorization are not required to access data.
- Errors handling -> Assume that errors handling/logging will be added later.
- Unit and e2e tests -> Assume that the full tests coverage would be provided later.
- CI -> Assume that CI will be implemented later (pre-commit hooks for prettier and linter, unit / e2e tests execution for PR's, tests coverage validation, package.json scanning).
- Caching and compression -> Assume that static content caching and compression policies will be defined later.
- Feature toggles -> Assume that feature toggles will be added later.
- Budgets -> Assume that budgets for bundles sizes, performance, and memory consumption will be defined later.
- Architecture -> Provide simple modular architecture.
- Securing -> Assume that content security requirements (CSP, Subresource Integrity) will be added later.
- Application versioning -> Assume that application version checker will be added later (service that would check if a new version is available every X minutes).
- Metrics collection -> Assume that metrics collection will be implemented later.
- GDPR / Copyrights -> Assume that no GDPR data is collected, cookies are not used for user tracking.