“The horror! Revoke his Angular2 license now!!”
I’m in no way saying this is a best practice or even a good practice. Including jQuery is not required or even desirable for most Angular2 applications. Angular1 had a dependency on jQuery or its own jQuery-lite version, but for Angular2 this is no longer the case.
jQuery will also cause problems for other scenarios, like pre-rendering the Angular2 application on the server or in a web worker, because jQuery components are expecting to work with the physical DOM. Plus it weights your application down with additional dependencies that will cause the application to load more slowly for a user.
But using jQuery was practical for this situation and gives me the chance to demonstrate how Angular2 can interoperate with existing web technologies. Let’s take a step back and look why jQuery might be worth considering in certain scenarios.
There’s been much discussion about creating general purpose user interface components (commonly called “widgets”). Think of widgets as resuable pieces of user interface that can help you to build your application, for example, a progress bar, a dynamic and sortable table view, menu bars, charts and graphs, etc.… Read more
Angular2 has a strong emphasis on components. An application is made up of a tree of components, starting from the root component and working down to child components. This helps to organize your application into logical and manageable pieces. Complex user interface can be broken down into smaller components, assembling them together, to better organize your application’s functionality and how it is presented to the user.
Components can be further categorized. Some components are just simple user interface components, for example like a date-picker widget or a simple user information card. These components are used throughout your application, but they don’t exercise your application logic. That work is delegated to other parts of the application. These components might be called “Presentation” (or “Dumb”) components.
Other components serve to organize and orchestrate the activities of child components and application services. These components know about the application logic. They might push application data down to child components and respond to events emitted by them. They might transform an event into a transition to a new application state. These components might be called “Container” (or “Smart”) components.
When I first started using AngularJS (way back in version 0.8, I believe), I was continually impressed at what it could do. The team I was working with at the time had many discussions on how this young framework could be used effectively within our project. We found ourselves experimenting with different techniques and slowly figuring out what patterns worked best. We were rewarded with many “Aha!!” moments that showed us how much insight went into the framework.
I’ve spent some time working with the new Angular2 framework and now have a better sense of how it is used. I think the Angular team has done a great job of improving the framework.
I’ve built an example application to manage a list of images. It’s not a full featured application, but I wanted to build something that had a reasonably complex user interface and also incorporated routes and UI controls (and wasn’t a To-Do application).… Read more
A while ago I whipped up a small utility to search for filenames at the command line. I noticed recently that it did not handle long filenames over 260 (MAX_PATH) characters. Having a few spare minutes I updated FastFileFinder to use the Win32 API directly as the .NET Framework Directory methods do not have that support. Additionally, I took at idea from Josh Carroll and batched up the matching filename output to minimize the calls to Console.WriteLine.
With that little bit of work FastFileFinder is now 30%-50% faster! I haven’t looked too much harder but I think there’s some more speed up work that can be done. Are you up for the challenge? How much faster can you make it go?
Grab the code here: https://github.com/Wintellect/FastFileFinder
Grab the compiled binary here: https://github.com/Wintellect/FastFileFinder/releases/tag/v2.0… Read more
It’s F# Advent time again! This is a yearly event the F# community comes together for the month of December and each person releases an F# related post on a day of their choosing. Today is that day for me this year.
With the recent announcement at Microsoft’s Connect() conference, Visual Studio Code now has an awesome update that can install extensions. With me being an F# fanatic I got excited to see that actually using F# is one of the first extensions available via Ionide which is originally made for developing in F# in GitHub’s Atom client.
While you could technically already “use” F# in Visual Studio Code, it was only for syntax highlighting. You couldn’t run any of the code. This quick post will help show you the steps to started developing F# within Visual Studio code.
Getting and installing modules is easier than ever with the PowerShell Gallery and PowerShellGet. Instead of downloading and extracting files into your PowerShell modules directory, a simple call to Install-Module takes care of everything for you. Today I’ve published my WintellectPowerShell module. Now you can install and get started setting up Visual Studio to access symbol server, source servers, and many other cmdlets for debugging support. All you need to do with PowerShell 5.0 (or by adding the Package Management Preview to PowerShell versions 3 or 4) is issue the following command:
If you haven’t heard of WintellectPowerShell, here are all the commands it offers.
One of the pain points of using Xamarin Forms is that, just to see updates of any UI updates via XAML, you still need to save your changes, recompile, and relaunch the application. What’s more, is that you’d have to do this on each platform you’re targeting to make sure the UI looks good on each of them.
Well, the awesome folks at Xamarin know this and they’ve just released a preview edition of their newest application – Xamarin Inspector. I’ve played around with it a bit and below are my first impressions of the new application.
Take note that, in the time of this writing, the Xamarin Inspector is currently in early preview. More up-to-date information can be found on Xamarin’s documentation page.
When playing with the Xamarin Inspector I decided to use the demo project that we used for our post a while ago on testing Xamarin applications with F# and FsUnit. I felt this application gave a minimal amount of UI just to see what the Inspector could show.
Since the Inspector is currently in preview, you would need to update your Xamarin Studio, in the
Xamarin Studio ->
Check for Updates screen to access the
Alpha channel of the updates, like below.… Read more
While this will be a short post it’s also one that may be one of the most important ones to go over – running unit tests. Most of you probably know that being able to run tests early and often can save a ton of time if issues are found later on. One way to do this is to be able to execute your tests as easy as possible and this is possible within your FAKE script. Once again, FAKE comes with functions to be able to execute our tests in any framework you may be using.
Of course, before running our tests we need to build the project. As we’ve seen in the previous posts, we’ll build the project with the MsBuild function.
let testProj = !! "FakeDemo.UnitTests/FakeDemo.UnitTests.csproj" Target "Build-UnitTests" (fun _ -> testProj |> MSBuild "FakeDemo.UnitTests\bin\Debug" "Build" [ ("Configuration", "Debug"); ("Platform", "Any CPU") ] |> Log "---Unit Test build output----" )
Now here is another cool thing I really like from FAKE – they include helper functions that execute the tests for us. All we need to do is to pass in some configuration and we’re good to go!… Read more
I’d like to share a really awesome bit of code that I’ve been using in my XAML applications for a while now… there are many frameworks and examples out there, but I’ve not yet seen anyone else using this exact technique before…
If you are building app UIs using XAML, then you are more likely than not also using the MVVM design pattern. The general idea is that your code which handles application logic, business rules, etc. gets placed into ViewModel classes, and all visual widgets/controls get placed into XAML views. Typically we would have one View per ViewModel, but that’s not a requirement at all (more like a generalized observation), and in fact there are some situations where we might want to have multiple Views for the same ViewModel (or break a complex ViewModel into multiple parts while still connecting to a single View). The ViewModels are supposed to capable of standing alone, and we use data bindings and command bindings to connect the two. This way, we can unit test our ViewModels thoroughly, and (sometimes) allow UX designers to dictate the XAML layout directly.
That’s all fairly normal and typical.
As we dig a little more deeply into the mechanisms of data binding, we learn that part of the “magic” is achieved by way of the INotifyPropertyChanged interface (which includes only one thing – an event named PropertyChanged).… Read more