We will go through a step-by-step example in building our own custom collection to see how all that works. Let’s dive in! ?

Throughout this article, I’m working with a Unit Tests project using .NET 5, C# 9.0 and NUnit. It makes it easier to play with the code on your own. We can create our custom collection and at the same time try it out in a foreach loop in a test method. I recommend this approach for testing out various programming concepts for yourself ?

Custom collection implementing IEnumerable<T>

First, we want to implement our own, custom collection in C#. The most obvious solution is to implement IEnumerable<T> interface. Our IDE will require our class to implement IEnumerator GetEnumerator() and IEnumerator IEnumerable.GetEnumerator() methods, so let’s do that:

Of course, this is just an example to satisfy the foreach loop, so we won’t care about the actual implementation of these methods ?

Custom collection implemented in such a way can be used in foreach loop:

Does foreach require IEnumerable?

Let’s try to get rid of implementing IEnumerable interface. As soon as we do it, our IDE complains:

Let’s try to remove IEnumerable.GetEnumerator() method completely, so our custom collection looks as follows:

Now guess what – we can still use MyCollection within the foreach loop!

So you already know that, when asked during an interview whether foreach needs a collection to implement IEnumerable, the answer is no ?

Custom IEnumerator

Currently, our collection has a single GetEnumerator() method returning IEnumerator<MyObject>. We already know that this method is needed in a collection to be able to use it within a foreach loop.

However, let’s work on what this method returns. We’ll implement our custom IEnumerator. Again – the most obvious solution is to create a class implementing IEnumerator<T> interface:

That’s the implementation proposed by the IDE (Rider). We can now change our collection to use this custom enumerator. See that it can still be used within foreach:

So far, so good. But why all these methods in MyObjectEnumerator? ?

Does foreach need an enumerator implementing IEnumerator?

If we remove inheritance from IEnumerator from MyObjectEnumerator, the IDE only complains about IEnumerator.Current property, so let’s get rid of it. Our custom enumerator now looks as follows:

Yeah, you guessed it again – we can still use our collection in a foreach loop ?

However… Does our custom enumerator really needs all of these stuff: MoveNext(), Reset(), Dispose() and MyObject Current ? Let’s remove all of them and see what our IDE tells us:

That’s the error from IDE when trying to iterate through our custom collection in foreach:

Type ‘ForeachFun.MyCollection’ cannot be used in ‘foreach’ statement because it neither implements ‘IEnumerable’ or ‘IEnumerable’, nor has suitable ‘GetEnumerator’ method which return type has ‘Current’ property and ‘MoveNext’ method

This error actually tells us everything. This is the ultimate answer to the legendary C# interview question: “What does a collection need to be able to use it in foreach loop?”. In other words: “Is it necessary for a collection to implement IEnumerable to use it in a foreach loop?”

The answer is: a collection needs to have a GetEnumerator() method returning an object of type having Current property and bool MoveNext() method. No interfaces are required anywhere here ?

The compiler uses duck typing to find these two necessary ingredients of the type returned from GetEnumerator(). It means that is looks for these properties by text. Later, depending on the type of Current property, a single element inside the foreach is typed accordingly. Only if this duck searching fails, the compiler checks whether the collection implements the interfaces.

In the end, this is our simplest and fully legit code (except the actual implementations of the methods, which is out of scope of this article):

Summary

I hope you got to know something new about foreach loop from this article. This may not sound like a knowledge you’d need on a daily basis, but it’s worth knowing how stuff works under the hood ? Plus, you can always score a point during your next interview ?!

The post Foreach, IEnumerable and IEnumerator in C# appeared first on Yumasoft.

But what you actually want is the real object present there:

After reading this article, you will know how to achieve that ?

JSON.NET circular references are the issue

Let’s take a look at our problematic JSON response object once again:

$ref: "1" is basically a reference to another object, which has already been serialized. In that case, the BestFriend field references the first element of the result array with $id: "1". It turns out that these are JSON.NET circular references. However, you don’t want these references in your client-side JS code – you need the actual objects to work with.

I struggled with this issue some time ago in my JavaScript code. In the beginning, I had no idea it might come from the fact that JSON.NET is used for serialization (thanks to our colleague Rafał for pointing that out to me ?). Let’s see what exactly happens here and why.

JSON.NET serialization

The JS example presented above shows a JSON result received from the following ASP.NET controller method:

This is the full content of json string after serialization:

Of course, this is great that JSON.NET does that. Why would we repeat the same objects multiple times in JSONs? The optimization here is that the same objects are serialized once and referenced from all places that use them.

However, if such JSONs are sent to the browser, fields with refs are of no use. We need the actual objects to be there, so we can process the results correctly using JavaScript.

Solution 1: fix the issue by reconfiguring JSON.NET serializer

The first obvious solution could be to configure JSON.NET to not use its optimization for references. Quickly searching through its documentation, we find that PreserveReferencesHandling setting is responsible for that.

If we change our controller’s code and serialize objects with PreserveReferencesHandling set to None:

Our JSON file will look exactly as we’d expect:

However, why would we disable JSON.NET circular references? This optimization can sometimes save us huge amounts of data to be sent over the wire. If you have thousands of objects, it might not make sense in sending them all to the client-side code.

You may also have no control of the backend/API you receive the data from. It might as well be dangerous to change the JSON serialization settings, especially if you work on a big project.

If reconfiguration of JSON.NET circular references serialization is not possible in your case, see the other solution (which we also use).

Solution 2: resolve circular references using JavaScript

So we are back to this state in JavaScript:

What we want is to have the full objects’ contents instead of $ref elements in our JSON result.

In fact, all the data we need is already there. The first element of the array with $id: "1" is object that should be put in place of all $ref: "1" references.

As you can imagine, this requires a mechanism that would traverse the results tree and replace all these values according to IDs of the referenced objects.

Fortunately, we don’t need to implement it ourselves. There are few implementations of such a tool, circulating the web.

We use something called JsonNetDecycle which we found few years back already. I noticed there’s a new version of it ported to TypeScript: jsonNetDecycle.ts. It doesn’t provide full type support as it is a few years old already, and I didn’t try it. But you can if you use TypeScript ? There’s also a cycle.js solution available here and recommended by many folks. I believe it may also solve our issue, but again – this is not what we are using.

The version of the JsonNetDecycle we use is this one. Simply create a new file called JsonNetDecycle.js in your project and copy this Gist’s contents to this file. You can skip the last part starting with (function(console) (line 112) – we won’t need it.

Now, we can use the exported JsonNetDecycle.retrocycle() function to “fix” our JSON:

Let’s see whether this works.

This is what we get from the API before resolving JSON.NET circular references:

So we still have references there instead of real objects.

Now let’s see what happens with the result object after executing JsonNetDecycle.retrocycle() on it:

Wohhooa! That’s what we wanted ? There are no circular references in our JSON response anymore!

The post How To Fix JSON.NET Circular References ($ref) In JavaScript appeared first on Yumasoft.