If I import a JavaScript package which uses PReact or other frameworks in my Svelte project, will Svelte compile it?
Will Svelte compile the PReact framework and the package using it? This should not lead to any performance issue or size issue for that matter, as PReact is small and Svelte will compile it.
But my question is still, will Svelte compile the PReact framework when I use it in my Svelte project? Because if so is it better to exclude it (not compile it) or just not care? I am wondering for best practices.
EDIT:
I'm importing FullCalendar which is a preact app
Svelte is a compiler in the sense that it takes .svelte files and turn them into .js (conceptually at least). After you've run the compiler, via bundler plugin or otherwise (e.g. directly through the compiler API), you end up with JS code that doesn't rely on a full-fledged runtime to be executed (we could call that "low level" JS from a framework perspective).
Said otherwise: Svelte's compilation is focused solely on transforming Svelte syntax (as found in .svelte files) into "raw" Javascript.
Svelte compiler has no notion of the rest of your code, outside of .svelte files -- for example, what comes from .js files in your codebase or, pertaining to your question, what comes from other libs like Preact. From the point of view of the compiler, they are just imports from the outside and, in the end, they are just variables in the Svelte code.
So the answer to your question is: no, Svelte won't compile Preact or anything that is not Svelte syntax.
Resolving external imports would be a problematic of your browser (if using raw ES imports) or, more typically, of your bundler (e.g. Rollup, Webpack...). It is the bundler that will read your import statements, try to resolve them in your node_modules, rewrite everything to play together, optionally apply some code transformations (like transforming TS, SCSS or Svelte to raw JS), optimize them, pack them together for optimal performance, etc. Svelte changes nothing in this regard.
As a more personal opinion, it doesn't seem to make a lot of sense to use Preact in Svelte. You essentially have everything you'd have in Preact already in Svelte. The reverse would seem more logical to me -- using some "framework agnostic" (once compiled) Svelte components in an existing app using another technology.
Related
I've done some googling, and haven't found a solid answer. In fact, I keep finding the exact opposite answer to my question (i.e., how to migrate TO TypeScript rather than from). As a TS newbie, I'm trying to consider the pros/cons of using it to pitch it to my org. My main question:
If we did adopt TS, what is the level of effort of removing it from a React project if we change our minds later?
My understanding is that TS transpiles to JS. If we wanted to switch to JS later on, we could simply take those transpiled JS files, check them into source, and remove the TS transpiler and files - no more TS. However, React itself has its own conventions that aren't plain JS, so I believe the transpiled files will be JS rather than JSX. Is there a method of transpiling React with TS to React directly that's as effortless as going directly to JS?
As per my comment, you can set jsx: "preserve" as an option in your TS configuration file, which will make the compiler forego transpiling the JSX into regular JS and output .jsx files you can use. Happy to help!
the easiest way is to create a new project
steps to do this.
run tsc
delete node modules folder
use your terminal to delete all ts files
exp: rm -r /.ts or //.tsx
copy the js code to a new react project
We are planning to switch new technologies like react for my CMS project which is under development for 10 years.
Until now everything was simple and plain on the front end.
First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.
But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.
After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.
But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.
Now the question
Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.
For the case I want to integrate ag-Grid to React also.
What I did not understand is that how to bring all these tools together.
I won't be able to use the simply include js way of react because of ag-Grid.
In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.
Each time before testing do I need to translate these files?
And more over if the files are translated does debugging become very
complicated?
Can babel make it on the run time? If yes is it a good practice.
There are lots of file in the node_modules folder. Which of them
should I include for production?
All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.
There are lots of questions and not a single step by step guide from beginning to production.
JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.
React can be written in plain ES5:
React.createElement("div", { foo: "foo" });
Instead of JSX:
<div foo="foo" />
Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.
The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).
Each time before testing do I need to translate these files?
They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).
And more over if the files are translated does debugging become very
complicated?
This is what source maps are for.
Can babel make it on the run time? If yes is it a good practice.
It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.
There are lots of file in the node_modules folder. Which of them
should I include for production?
The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.
I wrote a clojurescript project. It is a reagent component. Now i want to use this component in other clojurescript project. That is what i do: I compiled my cljs project and then i put a result compiled file to js folder in other project. Further i require that file from index.html. At the end i invoke my component from cljs file
(.slider-view (.-views js/swipe) (clj->js [[:p "1"]
[:p "2"]
[:p "3"]]))
and it works. But i have a question. My project and project where i connect my component have common requirements. For example React and ReactDOM. How to exclude this two references from my project and then connect it from another project? Is there alternative approaches? For example require cljs namespace from another cljs project directly
Even if you could prevent JavaScript libraries from being included twice, you will still have huge chunks of the ClojureScript standard library compiled in twice. As you suggested, you will want to put your first project on the classpath of your second project (by adding it to your project.clj or equivalent) and then include that namespace directly.
Building on Justin's quite correct answer...
What you describe is exactly the normal ClojureScript dependency relationship. In this case, the dependency is something you have created, rather than someone else's existing library, but it is still the same situation.
There is one important subtlety to note. You may want to develop both of your projects simultaneously. This may seem tricky, since dependencies normally require a version number, deploying, and all the rest of the heavy lifting that is just too painful for quick development.
Fortunately, the standard ClojureScript tooling offers a solution to this, called the Leiningen checkouts directory, which works by letting you put a symlink to your dependency inside your main project's directory.
Details are in the checkout-dependencies section of the Leiningen documentation; or just web search for "Clojure checkouts", if that ever decays.
As you get further into these techniques, you may hit some more subtle problems involving the Figwheel tooling. When you reach that stage, this article may also be useful.
I am looking to work on an Angular2 datepicker component as if for release and inclusion in multiple projects. What is the best way to structure the project for this compared to a regular Angular2 project built with angular-cli? Are there any examples of good starter projects/seeds for such a task? Or should the component library actually be an angular2 application itself?
My initial assumption was that I could just create a standard project with angular-cli which has a single module (e.g. MyDatepickerModule) which contains a hierarchy of components forming the datepicker however I don't know if this is the best way as I don't need everything that a full application provides.
Thanks for any guidance!
I would publish the library with AoT compatibility in mind.
This means compiling the source using the ngc compiler. In the distribution package I would publish the JS source, original html/css files, d.ts typings files and the ngc generated metadata.json files.
I recommend publishing the JS source with es2015 modules since this will make your library tree shakable. I would target es5 JS, but with es2015 modules . TypeScript allows for this hybrid mode by setting module to ES2015 and target to es5 in tsconfig.json.
Publishing these files will make your library AoT compatible and Tree shakable.
This is all the consuming application needs in order to AoT compile your library into their complete application.
It's not recommended to publish TypeScript in your package since this would require the consumer to replicate your build environment (typings + TS compiler version).
You can also publish a JiT compatible umd bundle with inlined templates and css. This can be helpful since it might not be practical do AoT during development since compilation is a bit slow. The umd bundle will make it possible to use your library in a JiT based dev environment. For production though you should definitely use the AoT version.
The CLI is not ideal for publishing libraries since CLI is primarily a tool for building complete applications. They might support libraries better in the future though.
Check out https://github.com/angular/material2. A work in progress, it's a library of controls and themes for Angular2 applying Material Design and is an excellent source for learning to build your own control library.
In the React Starter Kit they bundle with Webpack the server-side code into a server.js which I assumed can be handy but then I started wondering why bundling up the server-side code in the first place, after all Node comes with its own dependency management and doesn't need that. Second, wouldn't that even make it more inefficient due to parsing one whole file?
React code usually got written in ES6 however the Node doesn't support the es6 code yet, it can only understand es5. so if you want to use it without bundling and all the code will get complied first on the go. which will affect the performance eventually so you can use it for the development purpose but in production it is advised to use the bundled code.
So the major reason is Performance