Reading the actual HackerRank information was more interesting imho, and it's a shame imho that it's only linked at the very end of the article, since it's effectively a rehash of information in the HackerRank site.
Not sure why this was voted down specifically. Other than not using/mentioning `react-dom-server`[1]
Will mention that React rendering server-side can be slow and problematic. And should generally be limited to *ONLY* when SSO will be needed and effective. Google and Bing will both do client-side rendering as long as your routing is configured properly.
With some caching (depends on usage and again can be more complicated), you could do certain doughnut caching where only some modules are server-rendered and shared cached results. (Walmart did a lot of work towards this)
In general, it may have been easier to port the app to Next.js or similar, which would have been a little more consistent with the broader community.
[1] https://reactjs.org/docs/react-dom-server.html
I hadn't seen parcel before... but have used Axios. I can definitely see the appeal. I don't usually use it though.
My preference is a simple wrapper around Fetch-API. For Node, I set global.fetch = `node-fetch` in my service entry.
In general, limit notifications to only after asking (don't ask the first visit to your website, only on repeat), and only then ask for permission. Better still, after confirmation have a modal explaining that you are asking for the permission, why and what types of updates should be expected, and how often they will occur.
In practice, it's far more annoying than the marketers that send more than 1-2 messages a month for stuff you *did* opt in for.
I'm not going to downvote, but I will say these days notifications is the single most abused and intrusive feature in practice. It's *REALLY* bad form to do a notification request without positive user interaction before doing so.
Pretty much... doesn't bug me too much, but an annoyance all the same. Need to remember to take a look from home as I'm interested in seeing the video. May look to see if it's been cross-posted to youtube.
Yeah, it's a mixed bag, I usually wrap it up in something that works with my API structure better... (posting a gist to link now). The normalizeRequest[1] default export handles a lot of the issues for me. (note using elvis operator[2] via babel).
With that in place, a lot of my api-client comes down to things like:
import callAPI, { headRequest } from './request';
export const check = id =>
headRequest(`/petition/${encodeURIComponent(id.toUpperCase())}`).then(
r => r && r.statusCode === 200
);
export const dashboard = id =>
callAPI('GET', `/petition/${encodeURIComponent(id.toUpperCase())}/dashboard`);
export const create = petition => callAPI('POST', '/petition', petition);
[1] https://gist.github.com/tracker1/0b0522b840573171edffd31df50b381a
[2] https://babeljs.io/docs/en/babel-plugin-proposal-optional-chaining
If using material-ui, you will likely want to look at `mdi-material-ui` which is an icon package for material-ui using https://materialdesignicons.com/ which is more complete than the official icon library used by material-ui/icons.
Personally material-ui with react itself is hands down my favorite UI toolkit by a large margin. It's consistent, easy to use and customize, and everything from the components to the theming are working with the larger npm/react ecosystem instead of the NIH you get from other frameworks.
For me, I tend to put `node-fetch` onto `global.fetch` so that it's generally available like in modern browsers. If you have to support older browsers, could always use `isomorphic-fetch` for shared modules. I prefer to assume it's globally available and write to that.
It's not exactly the same, but close enough that I rarely have issue with client-server modules.