qqqq unlike in nuget feed git package feed doesnt display this file so to see it you need to look in the actual nuget package
This is a little project for testing the options for creating a wiki style pages to showcase each component on a github page. The same setup is ideal for testing as each component has its own page and the browser based no javascript tests require a page to go to test the component.
The testing project need prerender so needs server host client blazor webassembly so that the static (though we will put our nojs endpoint forms here) server html prerendered html can be provided before the webassembly which needs javascript to get onto the browser. If there is no javascript a pure webassembly project will not load anything.
This means testing requires webassembly prerender, github requires pure webassembly.
To acheive both there are two approaches in this project. For both, and because we are testing and displaying a package ultimately, we need the package project, and a project for components just for the wiki style component pages.
This leaves us with very slim projects for providing delivering the html/wasm.
Option 1: Have a prerender project for testing. This involves two project which is standard the server side and the client side. And have a seperate pure wasm project for github pages.
Option 2: Put in code in csproj and program.cs into the .client project that is release only. This allows us to publish it as a seperate project and get a pure wasm project. or run the server project debug for testing which because it is not release still works.
We also need a folder with an index.html end point for this.
Both these options work in this project.
The 404 page is because the Blazor is a spa the routing does not work as a github page, such that from the blazor entry point page you can get to and load your pages. But if you refresh those pages github will not find them at that route.
The 404 is picked up and redirects to index parses the request and index receives it and sends you there to side step this issue.
For the context we are using this project this is an ok approach.
It will need gitactions and it will need a hook maybe enforcing prepush rule to run tests as it may be prerender based test may not run in the pipeline?
Going into the pure wasm project or .client project and running a publish dotnet publish --configuration Release
Also DevServer needed adding to .client
See the page this creates in github:
See prototype project : https://github.com/TechnologyEnhancedLearning/MVCBlazor
This project is public which is required to be github page hosted
It should be at https://github.com/TechnologyEnhancedLearning.github.io/GitPageBlazorWASM https://technologyenhancedlearning.github.io/GitPageBlazorWASM/
<style> tr th:nth-child(2), tr td:nth-child(2) { white-space: nowrap; /* Prevent wrapping */ overflow: visible; /* Allow overflow */ text-overflow: unset; /* Remove ellipsis or clipping */ word-wrap: normal; /* Prevent word breaks */ word-break: normal; /* Prevent breaking within words */ } </style>| Description | File Structure |
|---|---|
| ┣ GitPageBlazorWASM | |
| The github page is aimed at this and gets the version from gh-page branch. .Client publishes a standalone wasm site here | ┣ docs |
| ┣ _content | |
| ┣ Package.BlazorComponentLibrary | |
| ┗ SharedPages | |
| ┗ css | |
| ┣ _framework | |
| Because its a spa we need to redirect 404 back to our index page parse them to take users to pages on refresh or if they go there directly | ┣ 404.html |
| ┗ index.html | |
| the pure webassembly project which was initially progressive publishes here | ┣ docsReferenceNow |
| ┣ _content | |
| ┣ Package.BlazorComponentLibrary | |
| ┗ SharedPages | |
| ┗ css | |
| ┣ _framework | |
| ┗ index.html | |
| just for making wiki style site if we decide to use the .client for testing and for creating the github page site then we dont need this | ┣ GitPageBlazorWASMProgressive |
| ┣ _Imports.razor | |
| ┣ App.razor | |
| ┗ Program.cs | |
| This would be out blazor component package | ┣ Package.BlazorComponentLibrary |
| ┣ _Imports.razor | |
| ┗ Components | |
| ┗ SimpleCounter.razor | |
| Bunit and E2E tests, the E2E none javascript tests require prerendering and hence the server wasm project for testing | ┣ PlaywrightXUnitGoesHere |
| ┗ UnitTest1.cs | |
| to keep the projects slim, and if we decide to have seperate programs for creating the sites we put the site in a seperate project that everything can use, this wouldnt be packaged | ┣ SharedPages |
| ┣ _Imports.razor | |
| there is just enough complexity to see things working | ┣ Layout |
| ┣ ComponentPageLayout.razor | |
| ┗ MainLayout.razor | |
| ┗ Pages | |
| ┣ ComponentPages | |
| ┗ CounterComponentPage.razor | |
| ┣ Error.razor | |
| ┗ Home.razor | |
| we need this for prerendering this is the same kind of set up we would use when we consume our libraries (though see MVCBlazor project for actual setup) | ┗ TestHostPrerenderWASM |
| slim | ┣ TestHostPrerenderWASM |
| ┣ Components | |
| ┣ _Imports.razor | |
| ┗ App.razor | |
| ┗ Program.cs | |
| the client is standalone on release and used by TestHostPrerenderWASM in debug for testing. Look for the release conditions to see how it does both | ┗ TestHostPrerenderWASM.Client |
| ┣ _Imports.razor | |
| ┣ App.razor | |
| if we put these in wwwroot then when running debug we would have two entry points so we keep them here and copy them on publish | ┣ GitPagesEntryPoint |
| ┣ 404.html | |
| ┗ index.html | |
| ┣ Program.cs | |
| ┗ Routes.razor |