Currently, C# LineNumbers property is just a string, but it can be a function as well in JavaScript. I'll figure out a way to achieve the same thing in C# and publish a new version of BlazorMonaco this weekend.

Hi @serdarciplak

Any news on this subject?

Sorry. I couldn't find time for this yet. But I see this as a priority item for this repo. I'll solve it asap.

I've added support for this in v2.1.0. Just set the LineNumbersLambda property of the construction options to a lambda and it will be called by the editor when needed.

Hi @serdarciplak and thanks for the attention.

I was testing, and when using the the new property LineNumbersLambda when the page loads the components, it throws the following:

My project runs on blazor-server-side, this functionality should be supported in this model?

I haven't tested it on a server-side app. I'll check it out.

Hi @serdarciplak

Did you manage to take the test?

Any news about this? I'm still seeing it running in server-side mode

How to customize line numbers using Blazor server

Tried to patch BlazorMonaco

Ok, I first tried to simply setup a callback using Blazor Server, but it didn't work throwing an exception saying that the InvokeMethod must be invokeMethodAsync

https://github.com/serdarciplak/BlazorMonaco/blob/master/BlazorMonaco/wwwroot/jsInterop.js#L112

So I tried to fork and patch my own version modifying the code to do invokeMethodAsync.

Well, it creates a promise so you can wait it or do a "then" and then see your callback code in C# being invoked... but it is impossible to return the value to the callback because it doesn't allow any form of async code (you can put a "then" and log the result and see it works, but it is not possible to return it).

Of course, the invokeMethod is good for webassembly, but won't work in Blazor server.

I wasn't able to figure out a solution this way, even checked the Monaco code but making this "lineNumbers" callback async would imply tons of changes afaik.

Workaround using some Javascript code

Basically, pass an array of strings or whatever to javascript and set the callback there.

On my EditorOnDidInit I invoked this code:

await JSRuntime.InvokeVoidAsync("setLineNumbersEditorCallback", "resultEditor", new int[]{});

where 'resultEditor' is the Id of my component:

       <StandaloneCodeEditor 
            Id="resultEditor" 
            @ref="_resultEditor" 
            ConstructionOptions="ResultEditorOptions" 
            OnDidInit="EditorOnDidInit"
            OnMouseDown="ResultEditorOnMouseDown" />

Then I added this javascript code in my page:

<script>
  function setLineNumbersEditorCallback(editorName, lines) {

    const editorElement = document.getElementById(editorName);
    if (!editorElement) {
        console.error(`Editor with ID "${editorId}" not found`);
        return;
    }

    // Get the actual Monaco editor instance from the global editors
    const editorInstance = monaco.editor.getEditors().find(e => e.getContainerDomNode() === editorElement);
    if (editorInstance) {
        editorInstance.updateOptions({ lineNumbers: (num) => {
            return lines[num];
        } 
        });    
    } else {
        console.error('Editor instance not found');
    }
  }
</script>

Actually my code is different because I pass a list of deleted lines, but you get the idea.

Hope it helps.

I finally had time to have a look at this and I think I have a fix. Here is an explanation of the new flow;

• A new JS-side cache is added for the line numbers.
• When MonacoEditor requests a line number for the first time, a dotnet call is initiated and an empty string is returned as the line number.
• When an async dotnet call completes, it adds the returned value to the JS-side cache.
• When all active dotnet calls complete, the line numbers are redrawn. In this redraw, the lineNumbers JS function returns the cached values and Monaco Editor displays these values as the line numbers.
• Also, a new editor instance method named ReloadLineNumbers is added. It can be used if the dotnet side needs to reset the JS-side cache and provide new line numbers.

@psantosl It would be great if you can review the PR #147 as you already know the context here.