TomasEkeli / ToDolittle

Sample todo app using the Dolittle framework
MIT License
1 stars 3 forks source link

[Dev experience]: maybe better not mix generated code in same folder as 'user' code #4

Closed paulvanbladel closed 5 years ago

paulvanbladel commented 5 years ago

In the web project, the proxy material is dropped into the feature folder, but the feature folder contains also the actual markup/js specific to the client implementation. It's always a good practice that generated code can be git ignored. That's quite cumbersome to do now because both user code and generated code are mixed in same folder structure.

So, the build of the .net triggers the generation of the proxy material. Can this drop location be configured somewhere ?

TomasEkeli commented 5 years ago

This is configured in the Core.csproj -file as "DolittleProxiesBasePath". As long as you do commit the files in Core/.dolittle any build should regenerate them exactly.

We always commit these, though, as they're used by the front-end.

pavsaund commented 5 years ago

The proxy generation is intended to be used side-by-side the frontend application code. The intention being that as much as possible to maintain the feature-structure across all concerns (domain, events, queries and interaction). Thus making it very much part of the application code.

As @TomasEkeli mentioned, you can easily change this convention so the output would be to a well known proxy folder and not interfere with the frontend application structure. It would then be completely up to you if you want to use these artifacts at all in the application.

On a side-note, down the line there will be more proxies generated for ex: input and business validation as we extend the support and components for each framework. I don't know of any specifics about this right now, though.