Somewhat a Full Stack Developer.
Nothing here yet.
No blogs yet.
Hello, No it is not. componentWillMount might be called multiple times (since react fiber) and it is not the best place to hold JavaScript's Call Stack specially. The place best life cycle method to place calls is within componentDidMount as it is only called once in the life cycle of the component. Refer to: https://medium.com/@baphemot/understanding-reactjs-component-life-cycle-823a640b3e8d
I'd assume that Normal user and Admin user just change in permissions mostly right? So they would be the same model, except they would have a property which would separate the two: const userSchema = new Schema({ name: String , email: String , isAdmin: Boolean }) If you wanted to complicate things a bit more, you could have roles: const userSchema = new Schema({ name: String , email: String , roles: [ String ] // ["admin", "moderator"] }) If you wanted to further increase the complexity, you could use a schema instead of a String for the roles const roleSchema = new Schema({ name: String // more properties here }) const user = new Schema({ name: String , email: String , roles: [roleSchema] }) So either way, once you had a hold of your user document you could just check for the property which dictated if it was an admin or not. const user = await UserModel.findById(userId).exec() // don't continue if not the admin if (!user.isAdmin) return ; The one thing I'd like you to retain is that when you're thinking about database you would want to figure out "what information is the same?" So regarding Admin and User, what information does the User model hold for both of them? Etc... If it were the case you really wanted to separate both, you would probably have a User model, which held the schema for the information that was the same for both of them, and then a RegularUser and AdminUser schemas. const userSchema = new Schema({ name: String , email: String }) const regularUserSchema = new Schema({ user: userSchema, // regular-only properties }) const adminUserSchema = new Schema({ user: userSchema, // admin-only properties }) Something along those lines I believe. Please bare in mind this is a very simple example!
Are we talking professional context here? Depending on your company you'll be creating technical debt without the time to "pay" it . There was a time I'd stop and try to refactor but then I realised time was going by and I still had stuff to do so making things work was the smart answer at that time. If you're talking personal projects, depends right? Are you building a product and on your way to an MVP? You really should not get into the refactoring loop until you have things up and running because you will only delay your project. Are you submitting to your github? Then yes, you should get into the refactoring loop so you show what you're made of. Time for refactoring is when you have time and depending on the context when you're allowed to, and also when you're obligated to do it because there's no other way out and you'd end up spending more time creating more logic than it would be to refactor the one at hand. My opinion only though!
It is a blessing when someone else's perspective can change our own, such as your wife did with you. Had never thought about creativity versus certainty and it seems to me like a very interesting topic as well although some people work better following very strict structures and some others like to be creative and inventive but even within those two different types of people there are small things where they excel at and IMO that needs to be harvested - if anything to keep the person motivated as they realize their potential. So far I like your channel mostly due to the personal examples that you bring to the table - I feel like the more things are "tangible" the more you can relate to them and therefore the better you can understand them.
Hey there, I'd like to congratulate you on the channel - very interesting talks you have there. I haven't checked everything but I'm truly intrigued. I'm not sure you have talked about this but I often find my self wondering about the different aspects of software development and how different people have different strong points. I've met professionals who excel at finding the very best solutions, some others were amazing on finding the quickest solutions, others were great on business logic and how to apply it, etc... So with that in mind I'd love to know about the "adventure" of finding your true talent within software development and how can you invest in it, and even how can you cope with understanding that your strong point might not be what you invested so hard at. I know this might seem like a very "open" topic but personally I love to find strong points in other people so I can motivate them to embrace it and bring out the best in them by investing in what they're already good at.
I think it's also good to add that you can use WebComponents with React/Vue. So in a way WebComponents are nice to share as you can use them anywhere with any JavaScript library or framework that works with HTML. Pankaj Patel very nice answer, although I'd like to ask you as native WebComponents are more performant?
I started with VueJS because I worked with Laravel and I do enjoy coding in it quite a lot. As far as I have read coders say that VueJS is quite easy to get used to as compared to React / Angular. The problem for me about VueJS is that it is not supported, as far as I know, by any big entity and it's heavily dependent on Evan and maybe a few other contributors, but that doesn't help with prosperity I guess. Plus if you need to turn to Native you'll need to use Weex (as opposed to React where you have React-Native). Given that you're coming from Laravel I highly recommend VueJS. You'll get the experience you need with a FE framework and that will give you the mindset to learn any other FE framework you see fit. Happy coding!
Currently you don't see much vanilla PHP, you instead see frameworks such as Laravel and that changes things quite a bit, because most of the work is done for you, and proven since in the case of Laravel it's already in version 5.4 and it's trusted by a big community, it's not something that was 'born' yesterday. If you're purely thinking on Backend, it quite depends on your goal. If you're doing it for fun Golang is taking the spotlight, everyone is turning to it, and according to articles I've read the popularity is only going to go up. Nodejs on the other hand, as well as JavaScript in general, is being bashed in the head by people saying how bad it is, yadda yadda yadda, they say the same about PHP, and then you just pick a language and there will be supporters and haters. Nodejs would help you in front-end as it's more javascript, you'll learn pretty cool things, but at the same time having the same language in front and backend is in my opinion bad as you just get used to thinking the same way, in the same language, and the world as it is doesn't favor that as much. Say you're looking for a job, my personal experience is "you have to know a bit about everything" because eventually, this again is my experience, you'll have to tackle different things. So... tl;dr: If for fun I would lean towards Golang, if professionally I'd go towards Nodejs (if I wanted to get deeper into JS and just work with one language), but if I wanted to check PHP again I'd turn to Laravel (given it's popularity and quite honestly from personal experience is a really good framework).