AngelMunoz / perla-templates

A repository with samples showcasing what can the perla dev server do today
https://github.com/AngelMunoz/Perla
8 stars 2 forks source link

Some feedback while playing around with this. #2

Closed nojaf closed 2 years ago

nojaf commented 2 years ago

Hello, I'm currently on a machine where I refuse to install Node.Js, so it was an opportune moment to try out Perla. I've played around with the fable-feliz sample.

I'm going to write down some findings I had:

A bit later I realized that I actually needed to use http://localhost:7331/#/hello, the routing is configured using # but I believe my remark still stands.

Upon trying out the component, I got GET https://cdn.skypack.devreact-snowfall/ net::ERR_NAME_NOT_RESOLVED in the browser and this looks like a bug while resolving react-snowfall from the CDN. It seems to be missing a slash somewhere.

My findings all might sound a bit negative but I really see the potential of this project. It is impressive what you have so far and I'm curious to see where this goes. The best of luck!

AngelMunoz commented 2 years ago

Hey!

I'm glad you took some time to experiment with Perla I didn't expect an F# celebrity to pop into my notifications, thank you very much for the guidance and improvements you've made to fantomas! it really improves the F# editing experience.

The SPA fallback thing. It might be interesting to have this out of the box.

I completely agree I have hit this one myself https://github.com/AngelMunoz/Perla/issues/43

After running perla serve, I had to run go and look at the docs on which port the thing was running. It would be nice to have something printed to the output window that the devServer is ready at what address.

It actually shows as part of asp.net's output after starting the server but I guess the Fable compilation phase hid that away I'll try to find a way to sync that or at least not lose it

Changes to the index.html do not reload the page. I changed the title of the page and was expecting a reload.

Woops, I have not added that but I'll log an issue for that

I tried to add react-snowfall. dotnet perla add -p react-snowfall. On the first try I got an exception, Exception of type 'Perla.Types+PackageNotFoundException' was thrown., at. The second time it worked and it added "react-snowfall": "https://cdn.skypack.devreact-snowfall" to my perla.jsonc.

This is really weird but it means that skypack didn't had the package built before weird but it's possible I guess we should improve the output here when something is not found or fails to be added

What confuses me here a bit is that the other URLs are optimized ones, example "react": "https://cdn.skypack.dev/pin/react@v17.0.1-yH0aYV1FOvoIPeKBbHxg/mode=imports/optimized/react.js". As a user, this is a bit confusing. I was able to add the package, but it looks different

the import map is the real deal and what the browser ultimately uses that's why the urls are optimized there, the dpendencies node in perla.jsonc is just to have a quick glance over what you have added to your project

Would it not be possible to merge perla.jsonc.importmap into a node in perla,jsonc? I'm not sure how relevant it is to have two files. Although on the other hand, most package managers have two files as well, where the second is a lock file.

The main reason there are two files is that we're depending on a behavior browsers will have in the future, the import map is what actually tells the browser how to load these bare dependencies (i.e. `import {} from 'bare-identifier') rather than having to specify the whole name of the javascript file those dependencies and mapings are saved to the import map, rather than building the import map on each request and having it in memory I thought it would be better to just have it on the sources so you could actually know where you're loading things from, and if necessary modify it by hand (sometimes is needed)

In the case of the perla.jsonc the file is actually just showing the list of dependencies nothing else, it doesn't provide any other functionality, although some have suggested that we could use that to re-build an importmap in case someone accidentally deleted the real one.

I understand this is a source of confusion, to be honest I think I might remove the dependencies node and leave the import map only for that purpose

If my project would start to grow, I would miss HMR pretty fast I believe. But I understand it is a very tricky thing to implement.

Ahh yes HMR is something that I truly want to add but it is very very confusing to me how others have implemented it, it is on my list of things to add this year at some point that and plugins, it'll take some time though given that I'm the only active contributor and I tend to slow down the first half of the year

My findings all might sound a bit negative but I really see the potential of this project. It is impressive what you have so far and I'm curious to see where this goes.

By al means be my guest feedback is necessary to improve things without it I feel it simply stales given that it already does most of what I need, I don't think the feedback is negative at all it is more-less in the area I expected to receive feedback so it validates some things I have in mind

Thank you for your time and I really appreciate the time you took to give it a spin I'll open some issues thanks to this, if you have any other feedback feel free to send it my way I'm all for it Have a lovely Sunday!

nojaf commented 2 years ago

Hi,

Thank you for appreciating the feedback.

It actually shows as part of asp.net's output after starting the server but I guess the Fable compilation phase hid that away

Yes, that might have been the case.

the import map is the real deal and what the browser ultimately uses

I understand that, I'm just wondering if the import map needs to be a file on disk. Could it not be a part of the perla.jsonc and perla extracts the info and generates an endpoint for it to serve it. After building you would obviously want to have a separate file.

Some other things I found after this first write up:

AngelMunoz commented 2 years ago

Could it not be a part of the perla.jsonc and perla extracts the info and generates an endpoint for it to serve it.

Help me think about this, while remote import maps are not supported on any browser (even with shims/polyfills AFAIK they need to be inline in the index.html) maybe if we get rid of the separate import map (we inject it whenever we're serving the index.html file anyways) we could just write it directly to the index.html file right

The sample stopped working after trying out the latest Fable 3.7 beta. (Feliz.Router problem,Uncaught SyntaxError: The requested module '../Feliz.1.53.0/React.fs.js' does not provide an export named 'React_useCallbackRef_7C4B0DD6'). I'm not sure there is any bug in Perla or Fable, but if you have any idea what's going on, I'd like to report this somewhere.

Hmm I need to check this one out it looks weird

Changes to perla.jsonc are not being picked up while serve is running. I think Vite does this and it is a nice experience to restart the whole thing.

Sure thing I'll get an issue for that

When trying out https I got an invalid https cert in my browser. What do need to do to get around this? Would installing the ASP.NET developer certificate be enough?

Yes that should be enough

Larger question, how would you want to support this if users are not installing Perla using .NET.

Hmm this is a good question

Question: is it possible to use my own GitHub template. I have a very specific taste when it comes to writing Fable apps, so I was wondering if it were easy to create my own starter template.

Yes! one of the latest changes was adding support for precisely that

And that would be it (it is better explained in the docs though)

AngelMunoz commented 2 years ago

Just as a side note, the "template" must be a directory inside the github repository Example:

nojaf/perla-templates

my-template
  | src
    | ... other content ...
  | perla.jsonc
  | index.html
my-other-template
  | src
    | ... other content ...
  | perla.jsonc
  | index.html

So if you have special needs you should be able to make it just as you need it if you try it let me know how this templating system feels because I might add something like this for plugins as well (which I want them to be F# scripts)

nojaf commented 2 years ago

we could just write it directly to the index.html file right

Yeah, that sounds about right.

As for the templating, I would use Perla on a per-project basis. So, as a local tool. There I feel like I should be able to just point to a git repo in the new command.

dotnet perla new -t nojaf/perla-fable-react -n my-new-project

I get why you use subfolders right now, but if users are going to make their own templates, they probably are not going to have multiple. So the system should be flexible and allow templates from the root of a git repository, as well as from a subfolder (using a flag or so). Notice that I used nojaf/perla-fable-react, this should map to https://github.com/nojaf/perla-fable-react.git. If I'm using any other remote git repo, I should use the full URL.

AngelMunoz commented 2 years ago

Thanks for all of the feedback I'll try to create the issues over the weekend (or if you feel like it you can start opening in the main Perla repo) I tend to be a little slow during the start of the year

The sample stopped working after trying out the latest Fable 3.7 beta. (Feliz.Router problem,Uncaught SyntaxError: The requested module '../Feliz.1.53.0/React.fs.js' does not provide an export named 'React_useCallbackRef_7C4B0DD6'). I'm not sure there is any bug in Perla or Fable, but if you have any idea what's going on, I'd like to report this somewhere.

Yes I just made a fresh template and updated it to fable 3.7 beta and broke I think this might go in Fable's main repo it could possibly be related to some compiler plugin things

nojaf commented 2 years ago

Thank you for reporting the Fable issue!

AngelMunoz commented 2 years ago

thanks again for the feedback! I think I've created all the issues in regards to your feedback I will close this issue since this repo is specific for the templates, feel free to re-open if something is missing or add a new issue in the main perla's repo