giphygram

Demo

development version

production version

Prerequisite

Install git, node (v8.x.x+) + npm;
Install editorconfig into IDE;

Development

clone the repo
npm i
npm start
open http://localhost:3000/ in your browser

Linting (JS and styles) is run on every commit hook. To run linter manually execute npm run lint.

Unit tests are run on every push. To run tests manually execute npm t, watch mode - npm run test:watch.

For easier debugging redux store is exposed in development mode under window.store. Also redux-logger middleware logs every redux action.

Build

development

Run npm run build. The output directory is dist

production

Run npm run build:prod. The output directory is dist-prod

Rationale

Why preact.js?

Preact.js is a lightweight and fast alternative to React.js. At the same time is still supports all major React.js features and takes all the benefits from the community support/components development, migration in both directions is extremely easy. Read more about differences.

Why redux?

A de facto standard for state management in React.js applications. Perfectly works with Preact.js as well.

Why stylus?

Stylus is a powerfull CSS framework with a short and expressive syntax.

Why all dependecies have versions frozen?

Can't 100% trust to open-source. Unfortunately, not all open-source projects follow the semver guidelines which may lead to obvious fails in the application.

Why to debounce requesting the next page in Grid?

react-infinite-scroller is a nice component for infinite scrolling, but seems that it triggers data loading too many times. As a result - can't trust its page and debouncing - just not to overkill the backend with requests.

Things to imporve

User input could (should?) be debounced to avoid backend flooding;
react-infinite-scroller component is not perfect (too many loadMore calls, has some issues with scrolling continuation when the request fails). Could be replaced with a self-written or configuration tweaked;
Better error handling: so far just display an error splash in the bottom of the list. Errors could be more informative based on HTTP error codes. Potentially, repeat button could be added;
Better image source choice: for now choose between webp and gif sources only. In some cases mp4 could be a better choice (smaller size). Also screen size and device type are not taken into account (could load better images for desktop retina then mobile);
Use previews: in order to not overkill browser image preview could be shown first. Actual animation (gif, webp, mp4, ...) could be loaded on click;
Virtual list rendering: no need to store all the "previous" images rendered. It's enough to keep 3 "screens" of data and prerender (and potentially predownload) in both scrolling directions;
Responsive adaptation: even though the markup is quite resonsive - it's far away from perfect on mobile devices;
Dynamic configuration: currently configuration is embedded into the bundle. Could be more dynamic (ideally, grabbed from some server endpoint);
Better logging: at least data fetch errors could be sent to some remote server for analysis;
Better fetching algorithm: "obsolete" requests (for previous query) should be cancelled;
Better state management: to make the application moree performant - some additional libraries may be used (like reselect, Immutable.js). Though, for such a small application may be an overkill;
Add more tests (unit, UI, ...);

kirilknysh/giphygram