Chapters
43 Chapters
|
5:00:38
|
This course is archived!
While the concepts of this course are still largely applicable, it's built using an older version of Symfony (4) and React (16).
Login to bookmark this video
-
Course Code
Subscribe to download the code!Compatible PHP versions: ^7.2.0
Subscribe to download the code!Compatible PHP versions: ^7.2.0
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Subtitles
Subscribe to download the subtitles!
Subscribe to download the subtitles!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
41.
Reusable Components
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Subscribe to jump to this part in the video!
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
While the concepts of this course are still largely applicable, it's built using an older version of Symfony (4) and React (16).
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": "^7.2.0",
"ext-iconv": "*",
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"doctrine/annotations": "^1.0", // v1.8.0
"doctrine/doctrine-bundle": "^1.6", // 1.9.1
"doctrine/doctrine-cache-bundle": "^1.2", // 1.3.3
"doctrine/doctrine-fixtures-bundle": "~3.0", // 3.0.2
"doctrine/doctrine-migrations-bundle": "^1.2", // v1.3.1
"doctrine/orm": "^2.5", // v2.7.2
"friendsofsymfony/jsrouting-bundle": "^2.2", // 2.2.0
"friendsofsymfony/user-bundle": "dev-master#4125505ba6eba82ddf944378a3d636081c06da0c", // dev-master
"phpdocumentor/reflection-docblock": "^3.0|^4.0", // 4.3.0
"sensio/framework-extra-bundle": "^5.1", // v5.2.0
"symfony/asset": "^4.0", // v4.1.4
"symfony/cache": "^3.3|^4.0", // v4.1.4
"symfony/console": "^4.0", // v4.1.4
"symfony/flex": "^1.0", // v1.21.6
"symfony/form": "^4.0", // v4.1.4
"symfony/framework-bundle": "^4.0", // v4.1.4
"symfony/lts": "^4@dev", // dev-master
"symfony/monolog-bundle": "^3.1", // v3.3.0
"symfony/polyfill-apcu": "^1.0", // v1.9.0
"symfony/property-access": "^3.3|^4.0", // v4.1.4
"symfony/property-info": "^3.3|^4.0", // v4.1.4
"symfony/serializer": "^3.3|^4.0", // v4.1.4
"symfony/swiftmailer-bundle": "^3.1", // v3.2.3
"symfony/twig-bundle": "^4.0", // v4.1.4
"symfony/validator": "^4.0", // v4.1.4
"symfony/yaml": "^4.0", // v4.1.4
"twig/twig": "2.10.*" // v2.10.0
},
"require-dev": {
"easycorp/easy-log-handler": "^1.0.7", // v1.0.7
"symfony/debug-bundle": "^3.3|^4.0", // v4.1.4
"symfony/dotenv": "^4.0", // v4.1.4
"symfony/maker-bundle": "^1.5", // v1.5.0
"symfony/phpunit-bridge": "^4.0", // v4.1.4
"symfony/stopwatch": "^3.3|^4.0", // v4.1.4
"symfony/var-dumper": "^3.3|^4.0", // v4.1.4
"symfony/web-profiler-bundle": "^3.3|^4.0", // v4.1.4
"symfony/web-server-bundle": "^4.0" // v4.1.4
}
}
What JavaScript libraries does this tutorial use?
// package.json
{
"dependencies": {
"@babel/plugin-proposal-object-rest-spread": "^7.12.1" // 7.12.1
},
"devDependencies": {
"@babel/preset-react": "^7.0.0", // 7.12.5
"@symfony/webpack-encore": "^0.26.0", // 0.26.0
"babel-plugin-transform-object-rest-spread": "^6.26.0", // 6.26.0
"babel-plugin-transform-react-remove-prop-types": "^0.4.13", // 0.4.13
"bootstrap": "3", // 3.3.7
"copy-webpack-plugin": "^4.4.1", // 4.5.1
"core-js": "2", // 1.2.7
"eslint": "^4.19.1", // 4.19.1
"eslint-plugin-react": "^7.8.2", // 7.8.2
"font-awesome": "4", // 4.7.0
"jquery": "^3.3.1", // 3.3.1
"promise-polyfill": "^8.0.0", // 8.0.0
"prop-types": "^15.6.1", // 15.6.1
"react": "^16.3.2", // 16.4.0
"react-dom": "^16.3.2", // 16.4.0
"sass": "^1.29.0", // 1.29.0
"sass-loader": "^7.0.0", // 7.3.1
"sweetalert2": "^7.11.0", // 7.22.0
"uuid": "^3.2.1", // 3.4.0
"webpack-notifier": "^1.5.1", // 1.6.0
"whatwg-fetch": "^2.0.4" // 2.0.4
}
}
12 Comments
Hey Guys,
Is there a way to deal with phpstorm and the
ESLint: 'children' is missing in props validation?Hey Skylar!
Yes...ish - I checked into this too, because it also bothered me. Basically, as far as I can tell, if you care enough, you simply *do* need to manually define it as a valid prop - e.g. https://github.com/yannickc... - here's even more background - https://github.com/yannickc...
Cheers!
Will there be a problem if I add this to the Button.propTypes?
Button.propTypes = {<br /> <b>children: PropTypes.node.isRequired,</b><br /> className: PropTypes.string<br />};I don't think there should be a problem unless the Button component doesn't receive any children passed in
Just wanted to verify so React is intelligent enough not to render children as attributes. Since although we are getting the attributes from {otherProps} the children props didn't get set
Hey Graymath technology
So, React excludes the children props of a component from
propsfield by default?Cheers!
What I meant was that the code below
<button classname="{`btn" ${classname}`}="" {...otherprops}="">{props.children}</button>
when I inspect this section in browser I don't see any of the child attributes populated in front of the class className attribute. But if I check otherProps in console I can see the children key is set on it
Ohh, so as you said, React detects that you are passing as an attribute the "children" property and it just ignores it. Right? :)
...otherProps
Woah, that's super nifty. Yay destructuring!
Haha, right!? :D
What would best practices be for source control for my re-usable components? Lets say I want to package my components so they could be used in other projects and by other developers?
Hey Amy anuszewski!
That's a great question! And when you start wanting to allow your components to be re-usable, several things change :). Most importantly, if you want to share your components, they're should be distributed as an node package. Npm - the registry node packages - does have paid accounts for private packages.
Typically, this also means that the components you want to reuse will need to live in their own git repository. However, I don't believe that's *required*. Especially when you first start developing something that will be reused later, it's a pain to store them in a separate repository, because you're probably hacking quickly on both those components and the first application that will use them. Having 2 separate repositories is clean, but can cause that initial building to slow things down. So, with npm, another option is that you *can* continue to store your reusable package inside your project... just in their own directory. When you publish your npm package (out of scope here, but I know a few things about this), you can literally just publish that *one* directory to npm. Suddenly, you only have 1 repository, but you have successfully published one of its directories as a private npm package. Other developers would install & use your package like normal.
If you have any other questions, I'd be happy to help answer them :).
Cheers!
"Houston: no signs of life"
Start the conversation!