vrbtm.co development stream | Week XII
No Redux, but Session and a stateful header
Not sure what this is, start here with our README, or catch up on the last stream, vrbtm.co development stream | Week XI.
I’ll be working on the following this week:
- User accounts setup
- Stateful header
- Implement Ant Design’s React component library
I’ve probably spent an hour, hour and a half reading up on Redux. I’ve implemented a Flux-like pattern before with Vuex, but not within Meteor. Then I read a couple more articles about implementing Redux within Meteor, specifically this excellent article by Abhi Aiyer. The separation of UI state and domain state in that article confirmed my hunch on how this would be implemented, since the need arose from creating a stateful header (a UI component).
However, I think Redux is overkill right now. I’m inherently using a Flux-like pattern with my setup already by treating the Mongo database as a single source of truth/state and manipulating it through Meteor methods only. And so far, this is very manageable with little to no side-effects. So, how do I maintain global UI state? With Meteor’s Session, which I’ve also used before (before I ever got learned/implemented Flux). This’ll be enough for now.
Back at it after several days off in Chicago. It would be pretty cool if there was a Meteor specific Flux-like package that used Session as its store. Anyway, going to implement the stateful header now.
Now, just because I’m not implementing Redux doesn’t mean I have to go full $avage mode on this. I’m going to implement my own Flux-like pattern by using Meteor’s Session and a centralized Actions.js object that contains all UI state manipulations. Which seems to work pretty well for now.
Onto user accounts setup. Meteor’s great for this, it has an extensive accounts package as well as out-of-the-box styled forms and templating. I’m going to set up the base package for the conventional email + password accounts, as well as the Google OAuth package. Google OAuth is the easiest to set up, so I’ll do that first. The annoying thing about these Meteor packages is that they don’t explicitly say how to configure Google authentication credentials if you use the base packages with no styling/UI. I’ve done this before and remembered that I need to use ServiceConfiguration and install yet another package. Here’s the relevant code for that.
ServiceConfiguration.configurations.upsert({
'service': 'google'
}, {
$set: {
clientId: Meteor.settings.google.clientId,
secret: Meteor.settings.google.secret,
loginStyle: 'popup',
},
});I created a Google application from within their console and got some OAuth credentials which I plugged into the settings.json file. After that, it’s just a matter of firing Meteor.loginWithGoogle().
Setting up authentication with a traditional email and password however is a little more involved. I hate doing this shit. It’s 2016, we shouldn’t be rolling our own user authentication and people should just register with services they already trust (like Google, Facebook or Microsoft). However, people suck, users are dumb, and they will most likely want a traditional registration.
^ why I do not do UX
Before I dive into the email and password authentication, I’m going to implement Ant Design’s React component library. Procrastinating by doing other work that needs to get done anyway. This wasn’t as straightforward as I thought and required a good amount of reading. Followed by straight up diving into the npm package to figure out how import only the absolutely required styling and logic into the application. Not too bad, but I’m using LESS as well as SASS right now, just because of Ant Design. Whatevs, slap another layer.
It’s starting to feel a lot cleaner and much more consistent, since I can do extensive form validation and notifications with a lot less code. I did some extra theming to make it feel a little more inline with our visual direction, but we’re going to have to do complete overrides at some point. Which will probably mean rolling our own components (again) at some other point. I’m fine with that. We’re trying to make a lot of gains in a short amount of time. We’ll invest in a full pattern library when the time comes.
Back to traditional email and password authentication. Setting up a form to capture an email, password and a confirm password mechanic is easy. Extremely easy with Ant Design’s library too. However, there are certain flows that spawn off of this type of authentication like:
- Password reset
- Email verification
- Email and password management
- User enrollment without a password (I’ll touch on this next week)
Thankfully, Meteor handles all of this too. I’ll need to do some work to integrate it into the React router but it really shouldn’t be terribly difficult. The emails that are going to be sent out for the above will be sent from the Meteor server if I use the default Accounts package. They’re most likely going to be plaintext emails too. Kinda sucks to be sending emails out from Meteor and Sendgrid, but it’s not worth the effort of migrating that logic over to something custom and Sendgrid. I’m going to implement this next week.
Due to the Chicago trip, this was always going to be a light week. I got food poisoning which pushed my productivity way down.
Timing was 6h 7m.
Next week:
- Wrap up user authentication
- Implement user roles and permissions
- Integrate user accounts and content
- Some kind of dashboard
Read the other half of this week with Wes’ VRBTM Making It Up | Week XII where he models our finances.
We’d love to hear from you…
Get in touch at Founders@vrbtm.co, talk with us on twitter @vrbtm.co, and read our story on medium.
Wes Jones is on Twitter @WesJonesCo
Nick Dandakis is on Twitter @Dandakis
