DEV Community: Anu Viswan

Why explicit Threads cause overhead

Anu Viswan — Sat, 03 Apr 2021 04:40:12 +0000

Cheat Sheet for Path Markup Syntax

Anu Viswan — Sat, 20 Mar 2021 23:40:51 +0000

Path Markup Syntax allows WPF Developers to skip nested Segements and use a single line of code to draw multiple shapes. This cheat sheet provides a quick reference to the different syntax of Path Markup Syntax.

View Model First Approach using Caliburn Micro

Anu Viswan — Sun, 24 Jan 2021 09:19:40 +0000

While it is possible to use both View Model First and View First approach while using Caliburn Micro, I personally feel one should stick to one single appraoch thoughout your application. Mixing the two approaches would impact the readability of code adversely.

View Model First Approach
In this post we will look at the ViewModel first approach, which is the default approach used by Caliburn Micro. Simply stated, it uses ViewModel to recognize the associated View.

Let us assume we have a ShellViewModel class, which contains an instance of UserProfileViewModel, defined as in example code below.

public class ShellViewModel:Conductor<object>
{
    public UserProfileViewModel UserProfile { get; set; }

    public ShellViewModel()
    {
        UserProfile = IoC.Get<UserProfileViewModel>();
        UserProfile.Name = "Anu Viswan";
        UserProfile.Age = 37;
    }
}

The Xaml part, particularly the View detection is quite simpler here, thanks to the Caliburn Micro's conventions.

<ContentControl  x:Name="UserProfile"/>

The caliburn micro would detect the required View using the ViewLocator.LocateForModelType method. Following is how it looks like.

public static Func<Type, DependencyObject, object, UIElement> LocateForModelType = (modelType, displayLocation, context) =>{
    var viewTypeName = modelType.FullName.Replace("Model", string.Empty);
    if(context != null)
    {
        viewTypeName = viewTypeName.Remove(viewTypeName.Length - 4, 4);
        viewTypeName = viewTypeName + "." + context;
    }

    var viewType = (from assmebly in AssemblySource.Instance
                    from type in assmebly.GetExportedTypes()
                    where type.FullName == viewTypeName
                    select type).FirstOrDefault();

    return viewType == null
        ? new TextBlock { Text = string.Format("{0} not found.", viewTypeName) }
        : GetOrCreateViewType(viewType);
};

As you can observe, the method removes Model from the full name of the viewmodel to recognize the associate view. The parameter context brings us to an interesting scenario, which we will discuss a bit later. But for now, it becomes clear that how the naming conventions of Caliburn Micro works under the hood.

Custom naming conventions is easily possible with Caliburn Micro. But I guess that is another topic, which need's a post of its own.

Binding to Collection of ViewModel

For now, let us look into another scenario. Let us assume, we have a collection of ViewModels which needs to be displayed in an ItemsControl.

public class ShellViewModel:Conductor<object>
{
    public IEnumerable<UserProfileViewModel> UserProfileCollection { get; set; }
    public ShellViewModel()
    {
        UserProfileCollection = Enumerable.Range(1, 10).Select(x => new UserProfileViewModel { Name = $"Sample Name {x}", Age = 37 + x });
    }
}

Binding the collection to ItemsControl and displaying each of the Items in a ContentControl would require a minor change. The usage of View.Model attached property, which is defined as

public static DependencyProperty ModelProperty =
            DependencyPropertyHelper.RegisterAttached(
                "Model",
                typeof(object),
                typeof(View),
                null,
                OnModelChanged
                );


public static void SetModel(DependencyObject d, object value) {
    d.SetValue(ModelProperty, value);
}

public static object GetModel(DependencyObject d) {
    return d.GetValue(ModelProperty);
}

static void OnModelChanged(DependencyObject targetLocation, DependencyPropertyChangedEventArgs args)
{
    if (args.OldValue == args.NewValue) {
        return;
    }

    if (args.NewValue != null) {
        var context = GetContext(targetLocation);

        var view = ViewLocator.LocateForModel(args.NewValue, targetLocation, context);
        ViewModelBinder.Bind(args.NewValue, view, context);
        if (!SetContentProperty(targetLocation, view)) {

            Log.Warn("SetContentProperty failed for ViewLocator.LocateForModel, falling back to LocateForModelType");

            view = ViewLocator.LocateForModelType(args.NewValue.GetType(), targetLocation, context);

            SetContentProperty(targetLocation, view);
        }
    }
    else {
        SetContentProperty(targetLocation, args.NewValue);
    }
}

As you can observe, the View.Model attached property, under the hood uses the ViewLocator.LocateForModel method itself, which we had previously seen.

We have now seen how View.Model is defined, so let us go ahead and write our xaml to finish off the example.

<ItemsControl x:Name="UserProfileCollection">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <Border Grid.Row="1" BorderThickness="1" BorderBrush="LightGray">
                <ContentControl cal:View.Model="{Binding}"/>
            </Border>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

The Context Parameter - Multiple Views for single View Model

We had skipped the Context Parameter for the ViewLocator.LocateForModel method earlier. Let us now examine the role of the parameter in detail.

var viewTypeName = modelType.FullName.Replace("Model", string.Empty);
if(context != null)
{
    viewTypeName = viewTypeName.Remove(viewTypeName.Length - 4, 4);
    viewTypeName = viewTypeName + "." + context;
}

From the above code (from the ViewLocator.LocateForModel), it is obvious that if the context parameter is non-null value, then it would replace the View string with a . followed by the context string. With that in mind, let us build our alternative views using the following folder structure.

Let us now pass the context parameter in our example above using the attached property.

<ItemsControl.ItemTemplate>
    <DataTemplate>
        <Border Grid.Row="1" BorderThickness="1" BorderBrush="LightGray">
            <ContentControl cal:View.Model="{Binding}" cal:View.Context="StudentProfile"/>
        </Border>
    </DataTemplate>
</ItemsControl.ItemTemplate>

The UserProfileView would be now replaced with StudentProfile view which we have created in the previous step.

Conclusion
In this post, we examined how to name resolution happens behind the scene for Caliburn Micro in a View Model First approach. We will examine View First approach in a later post, but if you understand the difference between the approach, and the working of one, it becomes easier to expect the other should behave.

Computed Vs Methods Vs Watch

Anu Viswan — Sun, 17 Jan 2021 04:34:53 +0000

Computed Properties allows you to define auto calculated properties based on other properties. For example, you could have properties firstName and lastName, from which you could create a new property, fullName, which gets updated each time either firstName or lastName changes. For example,

 data() {
    return {
      firstName: "",
      lastName: "",
    };
  },
  computed: {
    FullName: function() {
      return this.firstName.concat(this.lastName);
    },
  }

The FullName property would be recomputed each time firstName or lastName changes. You could now use the FullName property just as if you it was a normal property.

<div>FirstName :{{ firstName }}</div>
<div>LastName :{{ lastName }}</div>
<div>FullName:{{ FullName }}</div>

Computed Property Vs Method

You would why a computed property and why not a method ? For example, you could achieve the above with following.

GetFullName() {
      return this.firstName + " " + this.lastName;
    },

This could be consumed from your code as following

<div>FirstName :{{ firstName }}</div>
<div>LastName :{{ lastName }}</div>
<div>FullName:{{ GetFullName() }}</div>

So what is the difference ? Well the difference lies in the fact that the Computed Properties are cached internally, which the methods are recalculated each time, even if the corresponding property doesn't change.

For demonstration, let us add another property to our component, age.

export default {
  name: "Home",
  data() {
    return {
      firstName: "",
      lastName: "",
      age: 0,
    };
  },
}

The properties are bound to input boxes as the following.

<div class="row">
  <div class="col-12 border py-3 bg-light">
    Inputs :
    <input v-model="firstName" placeholder="First Name" class="mx-2" />
    <input v-model="lastName" placeholder="Last Name" class="mx-2" />
    <input v-model="age" placeholder="Age" class="mx-2" />
  </div>
</div>

We will also define couple of computed properties and methods which would consumed in our code else where.

  computed: {
    ComputedFullName: function() {
      console.log("Calling Computed Full Method");
      return this.firstName + " " + this.lastName;
    },
    ComputedAge: function() {
      console.log("Calling Computed Age Method");
      return this.age + "Yrs";
    },
  },
  methods: {
    GetFullName() {
      console.log("Calling FullName Method");
     return this.firstName + " " + this.lastName;
    },
    GetAge() {
      console.log("Call Age Method");
      return this.age + "Yrs";
    },
  },

As you could observe, we have declared two computed properties, namely, ComputedFullName and ComputedAge. We also have a corresponding pair of methods namely GetFullName and GetAge.

We will use these properties and methods to display the values as following based on the input elements defined earlier.

<div class="row g-2">
  <div class="col-4 border">
    <div><b>Computed</b></div>
    <div>FirstName :{{ firstName }}</div>
    <div>LastName :{{ lastName }}</div>
    <div>FullName:{{ ComputedFullName }}</div>
    <div>Age:{{ ComputedAge }}</div>
  </div>
  <div class="col-4 border">
    <div><b>Methods</b></div>
    <div>FirstName :{{ firstName }}</div>
    <div>LastName :{{ lastName }}</div>
    <div>FullName:{{ GetFullName() }}</div>
    <div>Age:{{ GetAge() }}</div>
  </div>
</div>

Let us now build and run our application and observe how it behaves.

Type a single character in the First Name input element and observe the console window.

Calling Computed Full Method
Calling FullName Method
Call Age Method

Since the firstName changes, the ComputedFullName property is called. So is the GetFullName method. These are pretty much desired and expected.

However, you could also observe that despite no changes to the age input element (and hence age property), the GetAge() method has been invoked. That is not the case with ComputedAge property. This is because, the Calculated property would be reevaulated only if the reactive dependency changes. If the reactive depencency does not change, the cached value is retrieved by the computed property, which reevaluting the property again.

On other hand, the method would be reevaluted each time it is invoked, irrespective of any changes to the dependend properties.

Watched Properties

If you want to your vue application to react to a change in a certain property, you have the option to use Watch properties.

But wait, does that sound similar to computed property. Yes and No - the watched properties observe a particular property in component and react (invokes a call back) to the change. This could be used to recalculate fields, which has same effect as the computed method. Since the watch is executed only when a property changes, it does share the issue of being reevaluated unnecessarly, as with methods.

For example, let us write the watch for age property.

  data() {
    return {
      firstName: "",
      lastName: "",
      age: 0,
      ageString: "",
    };
  },
    watch: {
    age: function(value) {
      console.log("Watch Age : " + value);
      this.ageString = value + "Yrs";
    },
  },

The application would react to any changes to age property. In our call back in the given example, we are recalculating a property named ageString for each change in age. You might wonder how is it different from computed property and when you would hesistate to use the watch property.

In fact, I should stop calling it watch property. Watch is a call back, a reaction to a change. This as such doesn't expose any property. You need to do that yourself. Computed Property in contrast is a property by definition and reacts to changes to the reactive dependencies. In the cases, it might be a good idea to use computed property. The reason is obvious if you were to complete the example by providing a watch to calculate the full name.

data() {
    return {
      firstName: "",
      lastName: "",
      age: 0,
      fullName: "",
      ageString: "",
    };
  },
  watch: {
    firstName: function(value) {
      console.log("Watch FirstName : " + value);
      this.fullName = value + " " + this.lastName;
    },
    lastName: function(value) {
      console.log("Watch LastName : " + value);
      this.fullName = this.firstName + " " + value;
    },
    age: function(value) {
      console.log("Watch Age : " + value);
      this.ageString = value + "Yrs";
    },
  },

As you can observe, since a single watch would be observing a single property, you would need to define two watches to react to changes to both first name and last name. This would, as seen in the example above, result in duplicate code. This could be easily avoided by using `calculated properties.

As you would have observed, you could basically achieve the results with any of the above options. But the hidden implications are evident once your application grows and for the same reason, it is important to understand the subtle differences to ensure you use the right feature for your requirement.

Complete source code of the post could be accessed in my Github