I'm writing an addon that defines a StickyHeaderListComponent under addon, and import it according to the Components section of the addons section of the guides.
I'd like to write some tests + use the dummy app, but the dummy app doesn't have access to {{sticky-header-list}}. How can I import it?
The app folder is merged into the application which consumes the addon during the build.
So, The file sticky-header-list.js should be under app/components.
Best practice is to write a mixin which will include the entire code of the component under addon/mixins
// addon/mixins/sticky-header-list.js
export default Ember.Mixin.create({
//Put all the component code here
});
And the actual component will be
// app/components/sticky-header-list.js
import StickyHeaderListMixin from '<your-addon-name>/mixins/sticky-header-list';
export default Ember.Component.extend(StickyHeaderListMixin);
In that way, a developer that will install your addon can choose to use the mixin, since the component code is not available at dev time.
The mixin will be importable under the path <your-addon-name>/mixins/sticky-header-list.js.
You can see an example in my ember-cli-lightbox addon.
Related
I cannot seem to export then import a powerapps solution that has a canvas app that references a custom component. I'm using the powerapps portal to create the solution, where I add the canvas app that uses the custom component. When I export, download, and try to import the solution at this point it fails with the error:
error code 8004F036: The dependent component CustomControl (Id=xxx) does not exist. Failure trying to associate it with CanvasApp (Id=yyy) as a dependency. Missing dependency lookup type = EntityNameLookup.
If I first go to the solution and click 'add required objects' it will not add the custom component. If I manually add it, it shows it as added, but still after exporting, downloading, and importing, I get the same error. It would be great if someone knows the proper steps to get this working.
You will have to do this in 2 steps.
custom control (either you created on or you used from some 3 rd party) should be deployed (imported) to Target system. If it is managed solution from 3rd party then you might have solution.zip file use this and deploy to target system. If you created this custom control, then create separate solution and just add your custom control and deploy this solution.
Once custom control is imported, then deploy/import your powerapps solutions.
I downloaded conversejs 9.1.1 and I am trying to learn the plugin architecture by making my own custom plugin. I looked at the http-auth plugin here to see how to add a plugin.
https://github.com/conversejs/community-plugins/tree/master/packages/http-auth
To install the plugin it directs me to the instructions here:
https://m.conversejs.org/docs/html/plugin_development.html
I understand I have to modify my webpage to whitelist the plugin, but for some reason I can't grok a few things. Here is my awesome plugin which resides in a file called Hello-World.js
import { converse } from "#converse/headless/core";
const plugin = {
initialize() {
console.error("Hello World!")
}
}
if (typeof converse === "undefined") {
window.addEventListener(
'converse-loaded',
() => converse.plugins.add("Hello-World", plugin)
);
} else {
converse.plugins.add("Hello-World", plugin);
}
The htpp-auth.js has no imports, but WebStorm was complaining that converse was unknown so I had to add the import. Why does the http-auth plugin not have to do that?
I am not sure where the plugin code is supposed to live. I added Hello-World under src/plugins/Hello-World. Is this correct?
Maybe related to above, but to get the plugin to actually run in addition to whitelisting it in my webpage I had to modify converse.js and add import "./plugins/Hello-World/Hello-World.js" which makes me think I am missing something obvious as I would think adding a plugin shouldn't require you to change the base code.
If it matters I am testing my plugin by running make serve in the conversejs directory and directing my web-browser (Chrome) to localhost:8000/fullscreen.html
Thanks, Wray
The htpp-auth.js has no imports, but WebStorm was complaining that converse was unknown so I had to add the import. Why does the http-auth plugin not have to do that?
converse is available as a global once converse.js has been loaded via the <script> tag.
That's why there's the if (typeof converse === "undefined") { check at the end of the plugin. It waits for converse.js to be loaded if converse isn't yet defined.
I am not sure where the plugin code is supposed to live. I added Hello-World under src/plugins/Hello-World. Is this correct?
Most community plugins are developed in such a way that they're loaded separately via <script> tags. If you do it like that, it doesn't matter where they live.
Maybe related to above, but to get the plugin to actually run in addition to whitelisting it in my webpage I had to modify converse.js and add import "./plugins/Hello-World/Hello-World.js" which makes me think I am missing something obvious as I would think adding a plugin shouldn't require you to change the base code.
You can do it like that if you want to include your plugin inside a custom build of Converse, then you can also import stuff from converse.
The alternative is to load your plugin separately via a <script> tag, but then you can't import stuff and have to use the converse global and the closured _converse object that is passed to your plugin's initialize function.
I want to access a file from material.dart library ('src/material/search.dart';) so that I can access private fields (_somethingsomething) in it to create a widget.
I read a bit about part/part of and so on, but it seems that I am not using it properly.
Is something like this possible?
Steps: Copying a file from Flutter into your own app.
Create a file search_copy.dart, and copy the content of material's search.dart.
Remove the internal imports used in the file.
Instead add the import import 'package:flutter/material.dart' to search_copy.dart
Modify the new file according to your needs, like exposing the private field.
Import the file with a prefix import 'search_copy.dart' as search; so you don't get import conflicts with material itself.
When you want to access it do so like search.showSearch(context: context, delegate: delegate)
Note: The search.dart file is part of flutter itself which is BSD-licensed. (https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/search.dart)
License:
https://github.com/flutter/flutter/blob/master/packages/flutter/LICENSE
The answer is NO. And probably there is a reason why these fields are private since package owners (in this case, framework maintainers) do not want the developer to use the variables directly or change them in any way.
If you would like to adjust the code for the component in the material library, you could:
a) Create an issue under flutter repository and explain why you need to access the fields, maybe even create a POC by forking the repository and implementing your changes. The Flutter team may approve this and your changes will be a part of the framework - that's the beauty of open-source! However, there is no guarantee that it will happen.
b) Copy-paste the search.dart code to your project and adjust whatever is needed. This is a faster solution to your problem, however, now you should maintain this code by yourself, you would need to keep this component in sync with any Flutter update.
Im using the login example from the Meteor React Tutorial
meteor add accounts-ui accounts-password
Its all ok but Im trying to find the file and change it but I dont know where is it.
This is my code:
import { Blaze } from 'meteor/blaze';
export default class AccountsUIWrapper extends Component {
componentDidMount(){
this.view = Blaze.render(Template.loginButtons,
ReactDOM.findDOMNode(this.refs.container));
}
componentWillUnmount(){
Blaze.remove(this.view);
}
render(){
return <span ref="container"/>
}
}
And i have installed meteor add useraccounts:materialize
How can I put the template on this?
You need to put your component inside /imports/ui/ directory and name the file as AccountsUIWrapper.jsx
So it will be saved as /imports/ui/AccountsUIWrapper.jsx.
Then you can import your wrapped component inside /imports/ui/App.jsx file with:
import AccountsUIWrapper from './AccountsUIWrapper.jsx';
And then use it in your React render function in the same file as:
<AccountsUIWrapper />
The tutorial lays it out pretty clearly, including all the filenames and locations. You should be able to access their GitHub repository for the same.
If you want, for reference, you can also take a look at my code at this particular step back when when I did this tutorial myself.
Update: For useraccounts:materialize
The useraccounts:materialize package that you have mentioned depends on useraccounts:core package as its base. So you cannot apply useraccounts:materialize to default meteor accounts package directly.
Follow the instructions on useraccounts:core to set it up. You may need to remove accounts-ui as well, as it would likely clash with the above packages.
Then, go through the documentation for useraccounts that shows how to render their accounts template in Blaze.
After that, using the same way as shown in the tutorial, you should be able to create a new React wrapper for useraccounts:materialize Blaze template.
Here are links to boilerplate useraccounts:materialize code for Iron Router and Flow Router. From these you can take reference for the Blaze template code, which you can then wrap in React:
Boilerplate with iron:router
Boilerplate with FlowRouter
I'm wondering what the convention to use is when creating a component inside an addon project... If I generate a component in my addon project using ember-cli#0.2.0, the blueprint will create a js file in addon/components, a template in addon/templates/components, and a js file in app/components. The part I'm not real clear about is where templates should live for these components. If my component template requires a partial, I need to put the partial template in the app/templates directory. If it lives in the addon/templates directory, it can't be resolved. So the question is this: Is it best to put all the templates (the component template and the partials) in the app/templates directory or leave the component template in the addon/templates/components directory and the partial in the app/templates directory? The latter feels slightly disorganized and the former seems more correct only because of the behavior of the blueprint. Anyone have any insight?
Thanks in advance.
Ember-cli is under heavy development so a lot of the file structure is likely to change soon, but here on some insights on the current state of the folder structure and why it is arranged the way it is:
The app/ folder is what gets directly imported into your application. Helpers are pulled from here, which is why you have to have a file for each of your components in this folder. Additionally templates will get pulled from the main application here, and as such they will be accessible in the ways that templates are normally accessible in an ember app (render, partial, and standard resolution).
Some people choose to place all of their components code in app/, but this is a bad idea because the addon/ folder exists not only as a separation of your addons code, but as a way for it to be imported using ES6 imports. So, while you can't directly access the components under addon/components/, you can import them into your application like so:
import SomeComponent from 'some-addon/components/some-component'
This is very useful for addon consumers if they want to extend an addon to add some functionality.
Templates in addon get precompiled in the build tree, which makes addons a bit more robust (for instance if they are using a different version of htmlbars they will still be compatible with the base app). However, they are not accessible via the resolver, so you have to import them manually in your addon's components, which is why the blueprint for addon components looks like the following:
import Ember from 'ember';
import layout from '../templates/components/some-component';
export default Ember.Component.extend({
layout: layout
});
Styles for addons can either be placed in addon/styles/ or app/styles/. In addon/styles/ they are also precompiled and included in the application by default. I highly recommend including styles in app/styles because this makes them accessible using preprocessor imports in the base application:
#import some-addon/main.css
This makes them completely optional to users of the addon, without resorting to app.import and config trickery (which is good because nested addons _do not support app.import. Don't use it.)
NOTE: They are not automatically namespaced, so you should put your styles in a folder to make sure they aren't conflicting with other addons styles.
In summary:
Any addon code that does not need to be directly accessible by the base app via helpers, initializers, etc. Should live in addon/
Anything you want to be accessible by ES6 imports should live in addon/
Templates should live in addon/templates/ and be imported manually
Component stubs, initializers, and other files that should be included in the standard Ember build chain should live in app/
Styles should live in app/styles/ and should be namespaced in a folder (e.g. app/styles/some-addon/)
Don't use app.import.