I’m always curious as to what developers are using in their stacks.
Right now my preferred stack consists of Symfony 3 as a back end / API with a composer.json somewhat similar to:
I’ve largely bumped to Symfony 3.2, but the combination of bundles I use seems to remain fairly consistent. Actually I just noticed that the Faker Bundle should be a dev dependency there – my mistake.
I occasionally flirt with other languages / frameworks, but when I need to get things done, I default to Symfony 3 & PHP 7.
Things are somewhat different on the front end.
Then Angular 1 came along. I’m likely viewing the past through a transcluded lense provider (ho ho, that’s an attempt at a joke btw), but Angular 1 seemed to explode across enterprises almost overnight. The terminology put me off (as previously indicated – transclusion etc), but with so many companies using it, it was hard to ignore.
Angular 1 now seems to be in the process of being replaced. By what? Well, it depends on who you ask.
I’m favouring React, as you might have guessed from the recent video content. It works for me.
In between me settling on React, and actually feeling like I could be productive with it, Vue emerged.
Likely there’s 100+ others I haven’t even heard of, let alone intentionally ignored.
But React is just a view library. Around this you have to build your own stack. And a quick look at the jobs boards will tell you, almost every stack is different. React, and / or React Native? Redux or Mobx? Jest, Ava, Tape, Jasmine, or Mocha? Decided on Redux – then Sagas or Thunks?
Ultimately I’m relatively happy with my current choices (React, Redux, Redux Saga, Jest, btw) but having just tried a small side project with MobX, I’m eager to try it some more.
So I’m curious: what are you using in your current stack, and more interestingly, which parts of your stack do you enjoy, and which do you find painful? Please hit reply and let me know.
This week saw three new videos added to the site:
Firstly we covered branching in Git from the perspective of a developer who has never used Git before.
In this video we cover all of my most commonly used commands when working with branches, and then move on to a more real world scenario – handling merge conflicts.
Merge conflicts occur when two (or more) branches contain changes to the same line(s) in the same file(s). There are ways to reduce the chances of a merge request, but at some point you will have to deal with one. It needn’t be scary, and after this video you will have learned how merge conflicts occur, and how to resolve them.
In the past I have recorded some more specific videos for Git (https://codereviewvideos.com/course/git-goodness). If you have a specific topic in mind, I’d be happy to record a video on that subject.
Next up we continue on with our React / Redux / Redux Saga front end to our Symfony 3 API backend.
Throughout this – and the following – video you will see that the process we have already learned whilst implementing login is largely the same for Profiles. It’s also largely the same for pretty much any other screen you need to add. This sounds a little long winded, but hear me out:
The modern front end is just as big a beast as the back end. We’ve got build systems, automated test suites, complex state, authentication, routers, and a whole bunch more.
If you’re anything like me, you end up working on a bunch of projects concurrently. Therefore, you need to be able to switch your focus between multiple different environments with the least amount of friction.
Having a standard workflow – such as component > saga > reducer > repeat – really helps to maintain your sanity.
In this video we cover the component setup, along with adding in some security to ensure only logged in users can visit the profile page.
With our profile page restricted down to only users who are properly logged in, we can make certain assumptions about the application’s state when the user hits the profile page. Namely that they will have a user ID.
Using the user’s ID we can initiate a request for their profile stored in our Symfony 3 API.
However, as we are using Redux Saga, we won’t directly call the API from the component.
Instead, our component will dispatch an action to start the profile request.
We will then create a Saga to watch for these actions. When an action is ‘seen’, we can manage the flow more effectively from a dedicated function. This function will ensure our state is updated to indicate a Request is in progress, then await the outcome of that request, process the successful or failed outcomes, and finally ensure the request is stopped.
It does sound like a lot of work. I can understand why there are those with the opinion that this process is needless verbose. My personal opinion is that this process brings order to larger applications.
Until next week, take care, and happy coding.