I am building a desktop app that monitors some things and generates data about what it is monitoring. When the user wants to interact with the data the app starts a very simple web server. The server serves static pages and has a basic http API to serve the data. I use html as a universal UI, the user uses their browser to view and interact with the data.
I would like to rewrite my html/css/js into a component based web app using Google's Lit 2. I like the idea of plain web components but I noticed that Lit offers some great additional features. Not surprisingly, most of the Lit docs are geared toward a more traditional web environment with a build step. I want to see if I can keep my server as simple as possible and avoid traditional backend tools (typescript compilation, minification, etc). I would like to replace my current static html/css/js with Lit components in a series of simple js files.
Currently, my server serves my pages from a 'public' directory and has a minimal http API:
- public/
-- js/
-- css/
-- index.html
How should I use Lit in a system without a build step? What is the minimum set of Lit files I would need to serve along with my own javascript classes that inherit from LitElement?
2022 update: Starting with version 2.2.0, lit is also available as a pre-built bundle, see https://lit.dev/docs/getting-started/#use-bundles
<simple-greeting name="World"></simple-greeting>
<script type="module">
import {html, css, LitElement} from 'https://cdn.jsdelivr.net/gh/lit/dist#2.4.0/core/lit-core.min.js';
export class SimpleGreeting extends LitElement {
static get styles() {
return css`p { color: blue }`;
}
static get properties() {
return {
name: {type: String}
}
}
constructor() {
super();
this.name = 'Somebody';
}
render() {
return html`<p>Hello, ${this.name}!</p>`;
}
}
customElements.define('simple-greeting', SimpleGreeting);
</script>
Original answer:
The Lit team doesn't provide a pre-built bundle as of 2021-08-01, you have to build yourself (to resolve the bare module specifiers, such as import .. from 'lit-html', which are not supported by browsers yet)
If you're fine with relying on a third-party CDN and supporting modern browsers only, skypack is very useful, as you can simply import lit from 'https://cdn.skypack.dev/lit'; in a web page.
(If you open https://cdn.skypack.dev/lit and then the pinned URL specified in comments, you can see there are only 5 JS modules involved, so extracting them from lit's source by hand to host as part of your application shouldn't be very hard either.)
Related
I am exploring the development with Web Components, more specifically, it's Fast. However, it would take a long time to rebuild the project and refresh the page, then verify for the CSS modification. Is there any CSS hot reload solution for the Web components(Fast)? (I am using Webpack)
There is no out-of-box solution for HMR with Web Components in General. It really depends on how you are using Web Components. Are you relying on just Custom Elements and using CSS-in-JS with it or fully using ShadowDOM with encapsulated styles and the underlying framework to declare those styles.
You can consider building your own HMR driver. To do this, you need all the three things in order for enable HMR - the bundler (assuming Webpack already has it), the server (webpack's dev server or middleware) and your own application.
In you own application, you would add the driver as:
// RUN SOME BOOSTRAPPING CODE
// HMR interface
if (module.hot) {
// Capture hot update for a particular module
module.hot.accept("./style.css", () => {
// Logic to remove old stylesheet
});
}
If you look at the above code, you can notice that it is almost impossible to change StyleSheet if it is defined within the shadow root for each component. If you have some global CSS which gets added to top Document then it simpler to implement HMR by manipulating StyleSheet objects from the javascript. At least, you will get partial HMR. For other activities, you can fall back to automatic full page refresh.
I had a look at the open-wc generator. I can generate web component libraries and web component application but the generated README file and the documentation does not contain a description how to import a web component library into another library or into an application so that the library or application can use the dependency as a web component. Is there a sample but non trivial application build with open-wc that I can use to learn from?
My primary interest is to import several web component into a legacy application that does not use npm and rollup by itself. What would be the best way to do that?
What I have tried to do. I have created a library litelement-demo by running
npm init #open-wc
and I have created an application in the similar way. I have opted for using typescript in both cases. The README.md of libelement-demo states that it can be used in this way:
<script type="module">
import 'litelement-demo/litelement-demo.js';
</script>
<litelement-demo></litelement-demo>
I have added this snippet to the application's index.html and run
npm i --save ../litelement-demo
npm run build
but the 2nd command fails with the error message
(!) Unresolved dependencies
https://rollupjs.org/guide/en/#warning-treating-module-as-external-dependency
litelement-demo/litelement-demo.js (imported by inline-module-index-1.js)
The link in the error message does not help and neither the open webcomponent documentation nor the generated README.md files.
Typical web component is basically a class as follows:
// You can also use some external library and inherit from its base class.
// For example: LitElement
class BasicSetup extends HTMLElement {
constructor() {
super();
}
connectedCallback() {
// Template/DOM generation
}
// One or more methods...
}
// Registration
customElements.define('basic-setup', BasicSetup);
Have a look at a registration statement. Simply add this file in your HTML scripts section and you are done. You do not have to integrate with any existing library or solution. Wherever, you have HTML, you can simply use it as
<div>
<p>My Awesome web component</p>
<basic-setup></basic-setup>
</div>
You can also initialize the element with JavaScript using customElements.get(name) method if you do not have access to BasicSetup class reference.
// Get reference to basic-setup class assuming it is already registred.
const ClassRef = customElements.get('basic-setup');
// Initialize using constructor
const myCustomElm = new ClassRef();
// or use document.createElement
const myCustomElm = document.createElement('basic-setup');
document.body.appendChild(myCustomElm);
Since your legacy application doesn't use npm, you don't need to do anything with it an npm.
Just add in the head
<script type="module">
import 'litelement-demo/litelement-demo.js';
</script>
and then use
<litelement-demo></litelement-demo>
somewhere in your html. Nothing else needed to start working
In Deno, to import a TypeScript module, does your own code file have to be TypeScript? Or does Deno auto convert TypeScript to javascript before the module gets imported?
I want all my code files to be EcmaScript modules (js or mjs, but not ts).
Unlike everyone else these days, I want to avoid using TypeScript in my own code. I dislike the rigidity of static types and Typescript is not part of the EcmaScript standard. EcmaScript alone has all I need to manage big projects. To me, TypeScript is an antiquated technology that has not been necessary since the advent of ES6 modules. The types of problems TypeScript addresses are problems I do not have.
You can write your own code with JavaScript.
Suppose you have or are using a TypeScript file/module numbers.ts:
export function isEven(n: number): boolean {
if (n % 2 != 0) {
return false
}
return true;
}
You can import and run it with an app.js JavaScript script:
import { isEven } from "./module.ts";
const one = isEven(1)
const two = isEven(2)
console.log(one)
console.log(two)
Deno does the TypeScript convertion to JavaScript internally. The process is the same when using standard or 3rd party libraries. The folks at the Deno project went even further by adding it as a goal:
https://deno.land/manual/introduction
Browser compatible: The subset of Deno programs which are written
completely in JavaScript and do not use the global Deno namespace (or
feature test for it), ought to also be able to be run in a modern web
browser without change.
Name resolution must be fully qualified. There's a whole lot more about referencing type definitions in this dedicated page for using TypeScript:
https://deno.land/manual/getting_started/typescript
Deno supports both JavaScript and TypeScript as first class languages
at runtime. This means it requires fully qualified module names,
including the extension (or a server providing the correct media type)
Example:
import { config } from "https://deno.land/x/dotenv/mod.ts";
Following my example above you can use the bundle command to generate a single JavaScript file with all the dependencies. Bundling it will take my app.js and module.ts files and create a new file app.bundle.js which is JavaScript.
https://deno.land/manual/tools/bundler
$ deno bundle app.js app.bundle.js
Bundling file:///home/pomatti/projects/deno-sandbox/app.js
Emitting bundle to "app.bundle.js"
3111 bytes emmited.
$ deno run app.bundle.js
false
true
It can even be loaded in the browser:
Bundles can also be loaded in the web browser. The bundle is a
self-contained ES module, and so the attribute of type must be set to
"module". For example:
<script type="module" src="website.bundle.js"></script>
As for ECMAScript modules I would like to point out that TypeScript implements it as well.
https://github.com/microsoft/TypeScript/issues/2242
https://www.staging-typescript.org/docs/handbook/modules.html
Starting with ECMAScript 2015, JavaScript has a concept of modules.
TypeScript shares this concept.
Now, the "static type" discussion falls out of scope of this forum so I won't touch it here, but I believe I covered everything else.
I have a litElement that I will need to consume from another domain. My browser is Chrome, I am using 'polymer serve' and navigating directly to the es5-bundle.
The lit-element is very simple. Just some static text.
When I use 'polymer build' my entry HTML page gets compiled (or transformed). I see a reference to 'custom-elements-es5-adapter.js' is added, as well as other custom JavaScript. When I navigate to this entry page (in the build folder) everything works. However, if I replace that compiled version with the original uncompiled version I get an error in the chrome console 'define is not defined'.
Eventually I will be calling this from another domain and will not be building the HTML it with polymer.(I have already tried it cross-domain and it's not working)
What do I need to include in the client to consume the polymer lit-element?
Here is what I have:
<body>
<my-element></my-element>
<script src="../node_modules/#webcomponents/webcomponentsjs/webcomponents-loader.js"></script>
<script type="module" src="./components/my-element.js" crossorigin=""?</script>
</body>
lit-element requires a transform step. The files the browser consumes must be transformed. If you want to deploy your original source files, the web server to which you deploy them needs to perform the transform step itself (as polymer serve does).
Source: lit-element README:
LitElement is published on npm using JavaScript Modules. This means it
can take advantage of the standard native JavaScript module loader
available in all current major browsers.
However, since LitElement uses npm convention to reference
dependencies by name, a light transform to rewrite specifiers to URLs
is required to get it to run in the browser. The polymer-cli's
development server polymer serve automatically handles this transform.
Tools like WebPack and Rollup can also be used to serve and/or bundle
LitElement.
The lit-element README has an example that will run in a browser with no transform steps. The example loads the lit-element library as modules from unpkg like this:
<script type="module">
import {LitElement, html} from 'https://unpkg.com/#polymer/lit-element#latest/lit-element.js?module';
class MyElement extends LitElement {
...
</script>
<my-element></my-element>
That method is useful if you want to try out lit-element with less messing about, but the Polymer team doesn't recommend doing this in production; AFAIK unpkg has no guarantees about uptime or performance.
I'm trying to create a Web API project and a client-side web project, where the web project can access the API via ajax. Currently my project looks like this:
I saw this answer on here: Setting app a separate Web API project and ASP.NET app, which explains how the project url can be set to localhost:[port]/api.
But for ASP.NET 5 projects, the properties only have 3 tabs (as opposed to the several found in ASP.NET 4 projects):
What I'm wondering is:
Do I have to set this option somewhere else? (i.e project.json)
How would this work when I publish? Ideally I'd want [websiteURL]/api to serve up my API, whereas that link explicitly put localhost:8080.
Is having these as two projects a good idea? I could easily put API and web in the same project, but I like the separation of client-side and server-side logic.
Any help would be appreciated!
First Point:
Generally speaking in ASP.NET 5, the routing defaults are very good and should work out of the box without much in the way of configuration. You can use configuration and/or attribute based routing in your application (with a detailed overview of both here), although my personal preference is for the attributed approach. Provided you have the following line in your Startup.cs file (which you should have in a new project):
app.UseMvc();
you should be able to route requests to your api controllers in the fashion required (i.e. "/api/...") simply by using [Route] attributes as below (example taken from a standard generated ASP.NET 5 Web API application)
[Route("api/[controller]")]
public class ValuesController : Controller
{
[HttpGet]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
}
The above example will route any GET request made to "/api/values".
While this approach can be used to handle requests made to your api, in order to deliver the files needed for your front end javascript application/single page app, you will need to enable static file serving. If you add the following to the Configure method in your Startup.cs class:
app.UseStaticFiles();
this will allow your application to serve those static files - by default, these are served from the ‘wwwroot’ folder, although this can be changed in the project.json file if required. The files needed for your front end app should then be added to this folder. A tutorial on serving static files can be found here.
Second Point:
In my experience this will not be an issue when you publish your website - provided your server is set up correctly, you will not need to include the port when making a request - navigating to [yourwebsitename]/api/... will suffice.
Third point:
In my opinion this entirely depends on how large the project is likely to grow, although preference and opinion will vary from developer to developer. Generally speaking, if the project will remain small in scope then keeping both in a single project is perfectly ok, as unnecessary complexity is reduced. However it is also very useful as you have pointed out, to maintain a separation of concerns between projects. So aside from the organisational advantage of your approach, the respective dependencies of the two projects are/will be kept separate also.