Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I think this example is a good sell for ts & fuse-box #14

Open
matt-erhart opened this issue Sep 13, 2017 · 7 comments
Open

I think this example is a good sell for ts & fuse-box #14

matt-erhart opened this issue Sep 13, 2017 · 7 comments

Comments

@matt-erhart
Copy link

If I understand the tsconfig correctly, you've basically replaced babel with ts AND made ts stop complaining. More people should know about this as it lets them code as if they we're in babel (and not get any ide complains/build errors), but add a ts file (maybe just some interfaces to get good hinting) here and there. This is like the incremental adoption sell from flow. I'd recommend making this example more prominent (maybe a blog post) and explaining it's benefits/inner workings in detail. (tsc may be faster/less bloated/easier to config than babel as well). I think that would get a lot more people to try out fuse-box and ts (and we can shift the standards to our liking...muwahah).

@nchanged
Copy link
Contributor

@matt-erhart
Copy link
Author

Made some tweaks and added some comments here: https://github.com/matt-erhart/react_fusebox .

@nchanged
Copy link
Contributor

You should read up on the options, like hashes for example, it's all there

@matt-erhart
Copy link
Author

Oh yea, for sure, work in progress. Those are mainly placeholders for me, but also so you know the things people won't know (but also, I didn't need to know to get it work). I think in general, this kind of over commenting the examples would help a lot of new folks. Maybe I could PR an over commented example sometime?

@nchanged
Copy link
Contributor

Sure! that might help, also with links to the documentation

@matt-erhart
Copy link
Author

Yea, links is a good idea. I'll ask some maybe dumb questions along the way, but that's probably what a lot of people (esp. with limit time) need.

Does hashing add a random-ish string to filenames? Why is this important?

Do I have this right?

    output: "dist/$name.js", // $name comes from fuse.bundle('somename') e.g. "vendor" or "app". That name (perhaps with hashing) will be added by the htmlindex plugin to index.html.

For the bellow, what's the difference between an internal and external dependency (is it based on node_modules imports)? What's considered project/non-project files? Automatically execute '>' makes sense. For [], is it only including the index.jsx or is it also including it's non-node_module imports? Docs might need a bit more about what's happening behind the scenes with this for everyone to fully understand.

// ~ means 'Extract all external dependencies. Ignores the actual project files.'
  vendor = fuse.bundle("vendor").instructions("~ index.jsx"); 
  // > means 'Automatically executes a file on load'; [] means 'matches everything inside without dependencies'
  app = fuse.bundle("app").instructions("> [index.jsx]"); 

@nchanged
Copy link
Contributor

Does hashing add a random-ish string to filenames? Why is this important?
no it's not random. That's a checksum, probably you need to read up on that, that's for cache busting - a regular practice in webdev.
Join gitter if you want to have a chat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants