##PokeCheck

####Context and Features requirements As part of hiring process, a webapp must be implemented in about one week. The subject (see pdf) defines the following specifications for the webapp :

• show users a pictured list of Pokémons where
• one can search for a specific pokémon by name
• one can select a pokémon to view its main characteristics
• one can compare this selected Pokémon's characteristics with other pokémons of same type
• display a few of most recent tweets about the selected pokémon
• one can bookmark a given pokémon
• ... and a few bonuses depending on time left.

I added the following personal features :

• pagination of the list
• caching of already fetched data, so next visits will be almost instant, and user can consult site offline !
• user can freely choose to display 20(default), 40 or 100 pokémons per page

####Product preview

• first version (incomplete) can be viewed online at this address.
• Current version is available at Pokecheck2

####Tech stack: I chose the following technologies :

• ES7
• fetch and Caches API
• React / Redux / React-Router
• Webpack / Babel / ESLint with Create-React-App
• StandardJS Code Style
• Material-UI
• FlexboxGrid
• Recharts

I wished had enough time to try on Inferno, and WebWorkers/ServiceWorkers.

Images comes from official site Pokemon.com
Data comes from pokeapi.com/v2
All credits to them !

####Usage

git clone https://github.com/Sharlaan/pokecheck.git
cd pokecheck
npm i
npm start

Then navigate to http://localhost:3000 in your favorite browser.

####Notes

• since previous version were fetching paginated data, the requirement to show averages on Detail page could not be fulfilled.
  This version fixes the issue in a progressive way:
  Step1 fetches all pokemon names/IDs, then Step2 fetches their details in background.
  This implies you can't visualize average in chart (Detail page) till step2 is completely finished
  The Circular Progress component displayed in List shows the progress % for Details fetching.
  The server pokeapi.co can even block temporarily requests with ERROR: TOO MANY REQUESTS message
• while first version were relatively performant UX-wise, this isnot the case for this one:
  the background fetching / caching takes its fair share from the main thread, slowing down the rendering...
  I admit this is less than ideal and may consider implementing WebWorkers + ServiceWorkers, hopefully should alleviate this rendering slowness issue while still working for the functionality.

####fetching times On Chrome DevTools Panel, upon opening the List page, you check :

• Cached requests in Application tab > Caches > Cache Storage
• Averages object stored in Storages > Localstorage
• 6 fetching tunnels in Timeline tab, showing parallel requests towards pokeapi.co API

20.6 mins for 4.6MB (822 requests)
barely 2secs once all requests cached

Code for measuring from marks dispatched throughout the code:
(copy code to console)

// Define first each measures:
const marks = performance.getEntriesByType('mark')
marks.map((m, idx) => {
  if (idx === 0) return m
  performance.measure('measure' + idx, marks[idx - 1].name, m.name)
})
// ... then display them
const measures = performance.getEntriesByType('measure')
measures.map(m => console.debug(m.name, m.duration))

####Useful links #####Caching surge auto.appCache While it sound nice and simple, i renounced from it when i learnt it's a "douchebag to use properly" from Jake Archibald, and will soon be deprecated in favor of Service Workers and Caches API. developers.google.com Fetch API cache params

#####Responsive layout react-pure-grid is nice and simple but import bug not fixed at project release time... react-grid-layout most complete but also more complex, too much for the remaining time available final choice: FlexBoxGrid