Anyone that can point to any documentation on howto reuse code in lit-element.
The problem now is that if I declare an element, in my case a close-button and I want to reuse it by importing it into 2 or more lit-elements, there will be an error in the browser about the close-button being declared more than once.
Understandable enough, but how do I reuse a component, I could of course move the button to a separate file and add it to the document, but then there would be dependencies on that for other components to work.
Any suggestions
If close-button self-registers itself, with a call to customElements.define('close-button', ...), then you should be able to import its defining module and not have any errors due to the module caching behavior of JS.
You must have multiple customElements.define('close-button', ...) calls, so I'd make sure that 1) it's self-registering and you're not registering it again in each component that uses it, and 2) you're using standard JS modules.
After investigating a bit more, I concluded that sharing HTML templates might be the way to do it.
Related
I'm new to webpack, and am trying to get my head around how I can switch an existing project to using it (am now using React in parts of it, so it has become necessary).
The kinds of things I am uncertain about:
As the package.json contains all my server side stuff too, will it not try to compile all this into the bundle.js?
My project contains a huge number of statically served files, and also a load of EJS generated pages. What's the best method for converting everything to webpack, I'm thinking it's going to be a bit of a headache to switch everything to 'require' statements instead of tags, but I guess it's the only way of taking full advantage of the benefits of webpack? Are there any recommended methods (or even scripts that will handles these changes for me?!).
Webpack will take care of "tree shaking" for you -- that is, it will only include the modules that your entry points explicitly use, no matter what is in your package.json file.
Looks like there is some support for EJS already in Webpack. A good conversation of it is here: https://www.npmjs.com/package/ejs-simple-loader#purpose You can then transition gradually (or not at all) as need be.
1.The backend dependencies in your package.json is unrelated to your frontend stuff. You just need to indicate the correct entry points.
FYI Entry Points
2.My suggestion is that you can find one EJS loader in GitHub to solve it.
FYI Loader
I’m building an electron app. In it, I have a webview with a preload script. Inside said script, I’d like to use sweetalert.
I installed sweetalert with npm install --save sweetalert. Inside my script I load it with require('sweetalert') and call it with swal("Hello world!");. I now notice it doesn’t look right, as the alert is missing its required CSS file. But I’m loading it with require('sweetalert'), which is great since sweetalert can just remain in its directory inside node_modules and I don’t have to care for it, but its CSS is an integral part of it, and is not getting pulled the same way.
Now, what is the recommended way of solving this? Keep in mind I’m inside a javascript file and would like to remain that way. Do I really have to go get the CSS file and inject it in some way? And how would I do it correctly, since it is inside node_modules? After testing it, it seems like it can’t be done in this particular case due to Content Security Policy.
Either way, that seems so clunky in comparison to the require statement, it’d seem weird for a simpler solution to not be available.
You'll have to include it like you would normally do in a browser, for example in index.html. Copy it out of the module folder into your css folder if you have one and link it with the link tag. It depends on if you're using plain electron or some other boilerplate template with there is a gulp/grunt workflow on where to stick it but that's it really, electron is just a browser that's running your JS/html so it's really the exact same process. require only loads the JS module but not the styles.
if you wanted to include it dynamically you could use the same techniques as a regular browser for example (ex. document.write/create element).
I'm not familiar with sweetalert, but hopefully this helps.
Your syntax for require should be something similar to this.
var sweetalert = require('sweetalert')
You should then be able to access methods on the sweetalert object using the following syntax.
sweetalert.someMethod()
Remember requiring just returns a javascript object. Those objects usually have methods that will allow certain functionality. If you want to add sweetalert to your page, you will either need to inject it within the html, or the javascript within the sweetalert module will need to dynamically create html where the css is included. I hope that clarifies some things and helps you get a better sense of some of the inner workings.
What I want to do is really similar to this and this except I'm trying to figure out how to put an ArrayExtension inside a module.
I'm trying to get something similar to the way C# extension methods work, that way I can just import the module and I'll have my extra methods. The links I provided show how to extend an existing object, but I haven't been able to figure out how to encapsulate that into a module.
If you're targeting non-browser environments like node.js this will be possible because you will be able to pass references to your module's global members, such as Array, to other modules. Those other modules can then extend the passed in object and/or its prototype with extra functionality which will be only accessible by the calling module. Other modules would have to do the same in order to get these extensions; therefore, conflicts are minimized since imports are explicit.
However, in browser environments this is not the case since there is only one window object and any changes to its members are available everywhere. As soon as any of your modules extended Array those extensions would be available to all other modules -- increasing the possibility for conflicts and making the code harder to reason about.
With that said, there are patterns in JS, and therefore TypeScript, which should accomplish what you want. One such pattern is the 'mixin' pattern which allows you to add on extra functionality on an object instance basis. You could separate re-usable code into mixin modules which could then be applied to an object when needed, or even automatically in constructors. Take a look at this for a decent overview and implementation examples: http://javascriptweblog.wordpress.com/2011/05/31/a-fresh-look-at-javascript-mixins/
If you're trying to extend the built in Array type you can't do that within a module. You're extension will need to live in an ArrayEx.ts file and occur outside of any modules. The reason for that is that if you did it within a module you'd be extending the Foo.Array type which isn't the same as Array.
But you said you just want to be able import the module to have your extra methods show up and all you really need to do is add a /// <reference path='ArrayEx.ts' /> to any file you want the extension methods to be available to. This is essentially the same thing.
Using GEB I was using the Page Object Pattern to encapsulate information about the different pages statically.
I then refactored my GEB code to be used from a separate class so I could encapsulate common commands using method calls.
For example I would have a method login() which will call the appropriate GEB code to login to the website that I am testing. I would then have other common functions using method calls on a TestHelper class.
I wanted to move these common functions to the Pages that they act upon. For example a search page would have a search method, the login page would have the login method. This way I can build a library of pages which have all the common functionality on them for use across multiple GEB projects. Now to do this each page must have a handle on the geb.Browser therefore I would now have to instantiate each page in the test setup. By doing so I am no longer able to use the standard page object pattern.
to ReviewQueuePage
assert at(ReviewQueuePage)
The code above will throw a null pointer as the object is no longer able to be accessed in a static manner meaning I had to change the code to
go ReviewQueuePage.url
This removes all the functionality of using the class as a Page.
Does anyone have any solutions for encapsulating the data for each of the pages in way that it doesn't cause the pages to act differently.
This resource maybe of interest to you. http://adhockery.blogspot.com/2010/11/encapsulating-page-state-and-actions-in.html. It also has examples in git.
This also might be useful Passing state between pages when using geb & spock
I'm a bit confused. Are you looking for a way to share common code among multiple pages? This is the impression I get after reading your question several times, but I'm not quite sure. You mentioned "common functions". Well, common components can be encapsulated using Module objects. In each page that uses a common component, simply reference the module object in the page object.
I want to add a calendar control to a page that already includes Prototype and Scriptaculous. Not happy with any of the Prototype ones I could find, I'm considring using the YUI Calendar widget.
I this likely to cause any problems?
We have worked hard to make sure that YUI is safe to use with any other library. We namespace everything, as HermanD says, under only one required global (YAHOO) and one optional one (YAHOO_config). We don't modify native objects. And even though Protoype does modify native prototypes, we code defensively so that this doesn't break YUI functionality.
If you find any bugs in using the two together, please let us know.
Regards,
Eric
YUI Team
By default everything in YUI is within the YAHOO namespace, so as long as you sensibly apply namespaces to anything you use from YUI, I would have thought you should be ok.
See: http://developer.yahoo.com/yui/yahoo/
I successfully used the YUI tab control in an app I was already using Prototype and Scriptaculous in and had no problem. The weight of all that is a bit much though if you're looking at a publicly available app. I wouldn't care so much about an internal app, say for a company, but you might want to think about how much JavaScript you're making end users download and the number of separate files they're having to download for the page.