An Open Source Project I’m Very Interested In… May 8, 2019
Posted by kevinbe71 in Development, Javascript, node, TypeScript, Uncategorized, Web Development.Tags: Development, Javascript, node, TypeScript
add a comment
Deno, which, if all goes according to plan should hit the 1.0 mark at the end of the summer 2019, is a really cool project in the “Node” dev space.
“A secure JavaScript/TypeScript runtime built with V8, Rust, and Tokio”
A few of the most important issues in the “Javascript” development space are:
1. TypeScript always feels like an extra layer that requires more effort than it should.
2. Client and Server code, while mostly reusable, have some annoying differences (e.g. “global” vs “window”).
3. Security was an afterthought in Node.
4. Deep, deep, deep dependency graphs!
5. Offline development is more tricky than it should be.
Ryan Dahl aims to address these and a few other things with his second attempt at server-side Javascript. Deno is going to be pretty amazing if it delivers on what’s currently being promised. It does seem to be largely on track (or perhaps even ahead of schedule?) so 2019 is looking like a really great year in this space!
TypeScript Timeline October 13, 2018
Posted by kevinbe71 in Angular, Javascript, node, React, TypeScript, Uncategorized, Vue.Tags: Angular, angularjs, Javascript, node, React, release timeline, timeline, TypeScript, typescript releases, typescript timeline, Vue, vuejs
add a comment
TypeScript is a very cleverly architected solution to adding types to Javascript. The team behind it managed to create something that still allows the flexibility of Javascript while remaining 100% compatible with it (Javascript files are TypeScript files to the compiling and there’s even the allowJs option if you’re too lazy to rename your pure javascript files to .ts).
One of the best decisions they made was to support structural typing instead of requiring a strict type match (like many static languages do, e.g. Java and C#).
That said, as I’ve read more news about key companies adopting TypeScript I’ve always wondered how this matched up with the actual release timeline. So, I went to the effort today to put that together. The screenshot below is a very low resolution image, so it is purely meant as a thumbnail (you can click on it to navigate to the screenshot I took):
However, if you’d like to interact with the timeline, you can use this URL: TypeScript Timeline
React – Organizing Imports January 20, 2018
Posted by kevinbe71 in Javascript, React, TypeScript, Web Development.Tags: best practices, Code organization, Javascript, organizing code, React, TypeScript
1 comment so far
I’ve been using TypeScript with React code for a couple of years now so I’ve learned what works and what doesn’t, so I thought I’d share a little of that wisdom…
Over time you’ll find that your application code starts to grow and grow until it starts to become a bit messy and you need to organize things a little better. If you have some “best practices” in your toolbox you can avoid having to go back and change all your old… so I’ll share this little tip that will hopefully save you some time later: how to organize your imports.
import { Action, Dispatch, Store } from 'redux';
import * as ActionTypes
from '../../shared/constants/actions/ActionTypes';
import { FSAAction }
from '../../shared/models/actions/base';
import { ShowPersonImageActions }
from '../actions/workflows/ShowPersonImageActions';
import { StateTree }
from '../../shared/models/state/StateTree';
import {
WorkflowShowPersonImagesStepAction,
WorkflowShowPersionImagesAction
} from '../../shared/models/actions/workflow';
import { FSAWithType } from '../../shared/models/actions/base';
This may seem OK to you, but there’s actually a problem we’re not seeing because of all the clutter… so let’s do a little bit of categorizing & sorting alphabetically:
// externals
import { Action, Dispatch, Store } from 'redux';
// state
import { StateTree }
from '../../shared/models/state/StateTree';
// action creators
import { ShowPersonImageActions }
from '../actions/workflows/ShowPersonImageActions';
// consts/enums
import * as ActionTypes
from '../../shared/constants/actions/ActionTypes';
// interfaces
import {
WorkflowShowPersonImagesStepAction,
WorkflowShowPersionImagesAction
} from '../../shared/models/actions/workflow';
import { FSAAction }
from '../../shared/models/actions/base';
import { FSAWithType } from '../../shared/models/actions/base';
I like to put “externals” at the top, followed by the basic building blocks in order… “state” first because that’s where we’re getting our data from (think of ordering things a layer at a time). Next we have actions and the constants/enums that are used along with them and finally interfaces. I consider interfaces as the connecting glue that pulls everything together so I put them last.
Hopefully you will have noticed something at this point: grouping things into categories may have highlighted something… we have an import statement that can be combined!
import { FSAAction, FSAWithType } from '../../shared/models/actions/base';
Obviously this technique assumes that you’ve split out interfaces into separate files etc. and a few other code structuring rules are in place, but you should get the idea of how to apply this to you own projects. Let me know if you like the idea in comments below or if you have another approach that works for you.
Javascript Automated Testing October 12, 2016
Posted by kevinbe71 in Chrome, Firefox, Javascript, Testing, Web Development.Tags: automation, chai, es6, jasmine, Javascript, mocha, selenium, Testing
add a comment
I’ve just spent the last week exploring various options for automated testing using Javascript. It was a fairly painful process so I thought this may be good to write a blog post about to save someone that pain…
Here are the options that I looked at (released software only… there are some interesting products on the horizon like cypress.io etc. if you like the bleeding edge):
- Selenium + Jasmine (with jasmine-node to allow ES6)
- Nightwatch.js
- Nightmare
- Webdriver.io
I couldn’t get Selenium + Jasmine to run reliably- it kept on hitting the timeout (or perhaps not completing the test?). I explored many options for overriding the timeout and none of them worked. I wasted 2 days exploring this so I really felt that I gave it a fair shake.
Nightwatch.js – I’ll admit that I can’t recall what the issue was with Nightwatch.js… perhaps it just didn’t do things the way we needed it to.
Nightmare uses Electron so it has a similar approach to PhantomJS based testing. This doesn’t work for our use cases- we want to automate execution in 3 browsers (Firefox, Chrome and Microsoft Edge).
Webdriver.io was the last option I tried. This turned out to be the one that worked the best… but only after a bit of learning. The secret was using the synchronous version and pairing it with mocha and chai.
Hopefully this will help someone else… let me know in the comments if you’ve found a better option or if you reached the same conclusion.
