Display full msg in Elm Debugger sidebar

Show and Tell
1

Elm Debugger limits the length of the text it displays. This is especially annoying when I want to examine the entire message that I’ve received.

I’ve overwritten some code in Debugger to make it display full texts instead of eillipses.

It’s not the most legible text, but it has all information in there. I did it by replacing the messageToString function in elm-stuff/packages/elm-lang/virtual-dom/2.0.4/src/Native/Debugger.js with the following code:

function messageToString(value)  {
	var result = '';
	for (var key in value)
	{
		result = result + ' ' + messageToStringHelper(value[key]);
	}
	return result;
}

function toFlatArray(value, result)
{
	if (value['ctor'] === '[]')
	{
		return result;
	}
	else
	{
		var new_result = [...result, value['_0']];
		return toFlatArray(value['_1'], new_result);
	}
}

function messageToStringHelper(value)
{
	switch (typeof value)
	{
		case 'boolean':
			return value ? 'True' : 'False';
		case 'number':
			return value + '';
		case 'string':
			return addSlashes(value, false);
	}
	if (value instanceof String)
	{
		return '\'' + addSlashes(value, true) + '\'';
	}
	if (typeof value !== 'object' || value === null)
	{
		return '…';
	}
	if (typeof value === 'object' && !('ctor' in value))
	{
		var result = [];
		for (var key in value)
		{
			result.push(key + ': ' + messageToStringHelper(value[key]));
		}
		return '{' + result.join(', ') + '}';
	}
	if (value.ctor.match(/^\_Task/))
	{
		return '…';
	}
	if (value.ctor.match(/^\_Tuple/))
	{
		var tupleResult = [];
		for (var key in value)
		{
			if (key !== 'ctor')
			{
				tupleResult.push(value[key]);
			}
		}
		return '(' + tupleResult.map(messageToStringHelper).join(', ') + ')';
	}
	if (['<decoder>', '_Process', 'Set_elm_builtin', 'RBNode_elm_builtin', 'RBEmpty_elm_builtin'].indexOf(value.ctor) >= 0)
	{
		return '…';
	}
	if (value.ctor === '::')
	{
		var arrayResult = toFlatArray(value, []).map(messageToStringHelper);
		return '[' + arrayResult.join(', ') + ']';
	}
	if (typeof value === 'object')
	{
		var result = '';
		for (var key in value)
		{
			result = result + ' ' +  messageToStringHelper(value[key]);
		}
		return result;
	}
}

It definitely has a lot of room for improvement, so feel free to modify it! I hope it helps your development process.

6 Likes
2

Thanks for sharing. The default behavior certainly has some limits in terms of its utility for inspecting messages. Given that this is merely debugging code, I do not see any issues with this type of hack. As soon as an improved version of the debugger is released, I think anyone using this technique would happily move on.

3

It really depends on why would you like to display full messages but there is another simple solution without touching any third-party packages. One can simple add Debug.log "" msg to update function in a following way to get full messages in the console.

update: Msg -> Model -> (Model, Cmd Msg)
update msg model =
    let
        _ =
            Debug.log "" msg
    in
    -- UPDATE DETAILS
    ...
4

I usually just wrap the msg in the case expression like this:

case (Debug.log "msg" msg) of
    — ...

Less noisy than the let form in my opinion.

2 Likes
5

Yes, the point is still the same. It’s probably unnecessary to patch VirtualDom in order to see full messages.

6

I very much want my debugger to be better than a log statement in general as it would rather use a good tool than patch my code on off.

So I appreciate the patch as I was frustrated with this limit of the debugger when I was trying to demo the properties of elm.

2 Likes
7

Have you tried this one?

http://package.elm-lang.org/packages/jinjor/elm-time-travel/latest

3 Likes
8

I just saw the demo and it has several really neat ideas! I hope it makes it into 0.19!

9

That’s what I’d been doing, but once my app got complicated enough to get several dozen messages per minute, debugging through console window became too much of a hassle. That’s why I started looking into this alternative approach.

10

This one is less performant than the built in one. I think being entirely in non-kernel code means it has less opportunity to optimise memory usage - you can really notice this if you are doing animations. However, it is better in how it lets you explore the Msg and Model, and the filtering feature is almost very nice, but often not very useful due to nested Msgs.

11

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.