Photo by Liudmyla Denysiuk on Unsplash
This is part of my "Blogging my Homework" blog post series, the introductory post can be found here.
Update 22nd of September: I passed my Hedgehog assessment!
Welcome back to part two of my study guide for Web Application Development! In the previous post, we covered the practical side of the assessment, this time we cover the theoretical side.
There are nine areas where you will be assessed (in the form of Q & A) on your knowledge of React, we’ll cover each one as a separate section.
As part of your study material for this core skill, the documentation for React is cited as a good source of information especially the Main Concepts section. And whilst not part of the assessment you are expected to understand JSX and Elements.
Whilst these are not part of the assessment, you’re expected to have an understanding of them.
camelCase property naming convention instead of the one used for HTML attribute. e.g.
Useful properties of JSX:
- Prevents injection attacks by escaping any values embedded before rendering
- Represents objects
React elements are:
- Are plain objects and cheap to create, unlike browser DOM elements.
- Are not components (more on this later)
- Immutable, that is once created, you can’t change its children or attributes.
The Learn Tech resources provide a good starting point for understanding when we should use React or in fact any type of framework behind just HTML and CSS:
- Does your application require a lot of client-side business logic?
- Do you need simple and reusable components?
- Could your application benefit from selective reloading? I.e. does anything on the page need to react?
- Is an existing customer development team already using React or Node?
- Does your application require a lot of DOM manipulation?
- Would the customer benefit significantly from having fast page load times?
The last point I feel relates to the modern framework’s build tools that are optimising pages for faster load times rather than an attribute specific to React.
Now take a moment and think about your own idea for an application, if you answered, “Yes” to most of these questions then perhaps React is the best tool.
It’s also useful to think about when it would be inappropriate to React, here are some examples I could think of:
- Does the application remain static after it has been built i.e. a static site generator like Jekyll?
- Does the application not require any interaction beyond page navigation?
- We want to use the latest and greatest technology!
The last two I paraphrased from CSS-Tricks’ excellent When Does a Project Need React? article.
Components allow you to split UI into independent, reusable pieces that can be worked on in isolation.
If you’ve ever done Forms or Windows application development, you can think of the controls toolbox as being analogue to components.
Convention: Component names always start with a capital letter, this is because React trees components that start with a lowercase letter as DOM tags.
Components can refer to other components for their output. The convention is to create an
App component that calls other components. This is important to know for refactoring.
If we continue the analogue of controls for an application, then we can think of props (short for properties) as exactly the same thing. You define the properties of a control.
An alternative view again provided by the React page is that “props” are inputs and they return a React element describing what should appear on the screen.
Important: Props are read-only if your component modifies it’s own props it is considered “impure”. You cannot break this rule in React.
States are similar to props but are private and fully controllable by the component. Recall in the last section that props are immutable that is they are read-only.
States are private and fully controlled by the component.
- Do not modify states directly, always use
- State updates maybe asynchronous, this is because React may batch multiple
setState()calls into a single update for performance. Use the second form of
setState()and pass it a function rather than an object.
- State updates are merged
All the children of a component, children can be:
- Everything, don’t have to be other components
React says children are an opaque data structure (Reach.children)
- A quick intro to React’s props.children – codeburst
- React This Props Children - Learn.co
- A deep dive into children in React - Max Stoibers Blog
They act like event handling on DOM elements, there are syntactic differences:
- React events are named using camelCase rather than lower case.
- JSX you pass a function as an event handler rather than a string
- You must call
preventDefaultexplicitly rather than return
- Inline styling
- External stylesheets
- CSS module
Lifecycle hooks are used to free up resources components when they are destroyed.
- Set up (React parlance: mounting) using the
- Teardown (React parlance: unmounting) using the
Lifecycle methods ensure that valuable resources are freed up when a component is destroyed. By defining
componentDidMount (allocates) and
componentWillUnmount (frees) methods. This is probably analogue to programming languages that have a garbage collector.
- Context API (React)
- Component state (very basic)
- JS module singleton pattern
- The state of the state: React state management in 2018 - DEV Community 👩💻👨💻
- The 5 Types Of React Application State - James K Nelson
- Application State Management – kentcdodds
- Managing React Application State with Mobx — Full stack tutorial (Part 1)
- Integrations w/ Web Platform
- VS Code