That seems like it could work pretty well. I would think that giving it an example bindings project with a style that you like and then pointing it to API docs could work pretty well.

F# 9 added support for "Nullable Reference Types" (which is not on by default!). This will indicate when core .NET BCL methods return types with the nullable annotation as a warning / error.

I added a selection column on a page using ag-grid with a checkbox in the header to "Select All" rows.
Then I told Claude that the Select All checkbox needed to honor the active row filter. It saw that I already had bindings in the project and added a missing binding as part of the fix!

I’ll do Dec 22.

Glad it helped!
Sounds like an interesting idea.

Long files in F# don’t bother me. But I am always open to the idea of refactoring if it makes sense.

One thing i hate in most C# codebases is having code split between so many files.

F# makes it easier to have less files which I think is usually better.

I think that you generally do want to keep the view stuff in the view fn rather than in the update fn. However, I have become more pragmatic over the years, and Elmish does include Cmds / effects for a reason.

Also, I don’t want to clutter my model with transient toast message mechanisms.

I see toasts as a feedback mechanism to make the page more responsive. They are transient and not necessarily part of a requirement.

OTOH, I add less transient results to the model, like for example an ImportSummary. Usually results that are part of a requirement or that I want to test.

Your thread inspired me to create a blog post on the subject.
Hopefully it helps!

bsky.app/profile/jord...

I think you chose a good path using Fable-to-TS. Bindings are a tradeoff that I think *can* be worth it for FT, long term projects if you don’t mind occasionally adding here and there as needed. But as always - it just depends.

Maybe Glutinum can get it close enough for Claude to take over?

I test my Fable Elmish logic on the. NET side.

Here is an excerpt from CC's `init` generated markdown summary:

Key Patterns:
Functional Core, Imperative Shell: F# domain logic with C# AutoCAD adapters
Domain-Driven Design: Rich domain models with business logic encapsulated
Immutable transformations: Raceway modifications return new instances

I totally agree. Claude Code has been amazing with F#.
Creating a spec to modify domain code can be an added layer of indirection, and is less precise than just writing the code.
F# domain logic is so expressive that it is a spec unto itself. This is evidenced by how well CC summarized my project.