You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+8-3Lines changed: 8 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -151,9 +151,13 @@ over the data loading and give the users benefits of frontend cache data while t
151
151
and forwards in the search page.
152
152
153
153
I have also used this on the movie details page. You could argue here that the frontend cache is not as useful
154
-
as caching on the search page But should the users again go back and forth between search and movie details pages
155
-
maybe view the same page movie details multiple times then this will feel a little more performant to the user.
156
-
I also decide to be consistent across the two pages how their data is initialised and hydrated.
154
+
as caching on the search page. I also decide to be consistent across the two pages in how their data is initialised and hydrated.
155
+
So we have a standard data loading pattern.
156
+
157
+
Currently the Next.js Link component isn't always able to provide "Soft navigation",
158
+
where routing is solely via the frontend rather instead a full page load - but once this problem is resolved the page could take full
159
+
advantage of cache. In the meantime the page can be cached by setting the revalidate time of page.
160
+
157
161
158
162
### Styling
159
163
@@ -186,6 +190,7 @@ I had limited time so here are a few other things I would look at..
186
190
- Storybook for individual components - this would actually make working on the components a breeze.
187
191
- Better display for small screens - I would love to put more time into this, I think the search page could be optimised quite nicely for smaller screens
188
192
- You could even add additional image sizes to the api endpoint and use different image sizes for different media queries
193
+
- Pagination component could be more SEO friendly
189
194
- Optimise our endpoints but reducing the payload size - there is currently data we send to the frontend that isn't used
190
195
- It's not the prettiest web app (I'm not really a designer) again with a bit more time it would be good to put more polish on it terms of looks
0 commit comments