Based on recommendations for the preparation for Ember 2.0...
• In general, replace views + controllers with components
• Only use controllers at the route level...
...we're supposed to eschew Controllers and Views in favor of Components. I haven't been able to figure out and/or understand how to generate Components that aren't direct parents of the components folder, i.e. components/component-name.js.
My current controllers folder looks something like:
/controllers
/account
index.js
edit.js
/business
index.js
Basically, there are sub-folders that group logic based on the sections of the application. How do I accomplish this with just components?
Seeing that components must have a "-" in them, I tried, but get an error...
ember generate component account/index-module.js
You specified "account/index-module.js", but due to a bug in Handlebars (< 2.0) slashes within components/helpers are not allowed.
Do all components have to be like
components
account-index.js
account-new.js
business-index.js
i.e. all in the same folder? This will start to get out of hand with the addition of what I actually consider to be components (things like video-viewer.js, text-editor.js, radio-button.js).
I would really like to have components in sub-folders, but unsure how to do this.
components
/media
/audio
audio-player.js
/video
video-player.js
/text-editing
text-editor.js
editor-toolbar.js
My components folder is already gross and I just got started:
Is it okay to leave the account/business logic in Controllers (seeing that it does say you should only use controllers at the Route level)?
I'm really confused about this "all components, all the time" convention.
Ok, so I had the same problem and as of ember 1.9-beta.3 (that's the version I tested). It is possible to have components nested under resource directories.
That means that you can have a "user" route or resource. And let's say you have a component which you only want to use with the user resource, so you want to put the component under the resource directory.
The way to do it is to put the component under the resource directory app/pods/user/component-name/template.hbs. The important part is to remember that components must have a dash in their name. It can't be just .../user/component it has to be .../user/component-name with a dash. Then you can use the component as {{user/component-name}} in your templates.
Also I think this is only possible when you're using the pod structure.
Ok, I think this question/answer needs a bit of an update for 2019. I have been using Ember for all of about a month, and my components folder has already become a pigpen. And the tutorial and main API docs don't really cover how to organize your components.
So I did a search of course. And the only answers I could find (like this one) are from around 2014-2015, and don't reflect modern Ember. I was about to accept my fate when I found this in the Ember syntax conversion guide.
(Note to the Ember folks: This is an important issue, one that almost every new user will encounter. It should feature a bit more prominently in the documentation. Maybe not the tutorial, but definitely in Components section)
You can in fact generate components under a sub-folder in Ember as such:
$ ember generate component foo/bar-baz
installing component
create app/components/foo/bar-baz.js
create app/templates/components/foo/bar-baz.hbs
installing component-test
create tests/integration/components/foo/bar-baz-test.js
So that's great, the files are created under components/foo and templates/components/foo. And to resolve the name of the component for use in another template, you can use either the old style syntax:
{{foo/bar-baz }}
Or the new style angle bracket syntax:
<Foo::BarBaz />
As the assertion suggests this is due to Handlebars 1.x, and will be available soon.
Ember 1.9 beta builds currently support this, though I'm not positive if ember-cli's resolver would work with it right now. You can read more about Handlebars 2.0 here.
Using a pods structure will also help with organization, and I believe is going to be the recommended strategy going forward.
For now, I'd suggest not to worry about it! Remember the transition plan will be smooth, and as the official releases come out for Ember and Ember CLI, you'll get deprecation warnings.
Related
I am converting a svelte website to a sapper website. The current routing library had the ability to specify aliases for routes, so in my localized case, mydomain.com/hello-world and mydomain.com/vamos-companeros would be the same route/component, only the language on the page would change. I read this in the docs:
If you want to capture more params, you can create nested folders using the same naming convention: [slug]/[language].
but that unfortunately does not fit my use case. Anybody an idea whether and how this is accomplishable? Thanks in advance.
The way I did it now was to create a common component _component.svelte which would not get used as a route and move all my shared logic there. The components hello-world.svelte and vamos-companeros.svelte would reset title and meta tags and then pass the text for the page to _component.svelte, which renders them together with other shared assets like images.
I used error boundary inside (componentDidCatch)I want to log which react component is break in producation build.
conclusion is get react component Name inside componentDidCatch in producation build.
I read many article and below link this is same as I asked in question but it's not solve my problem.
Getting React Component by name
and I also saw some webpack related things (production config's uglify) but it's not proper clear.
let me know if any simplest way to solve this issue
By design, you should never be able to see debugging information in a production build. What you are trying to accomplish here is an anti-pattern. However, if you still want to go through with it, you can use:
this._reactInternalFiber.elementType.name
Note that it might be instable due to using a private property that belongs to React.
https://www.reddit.com/r/Clojure/comments/4el0xi/how_to_use_an_existing_reactjs_component_with/
There is this existing post about using existing ReactJS components in a CLJS/Reagent project. I'm looking to do the opposite. I have a bunch of CLJS components and would like to compile them into a ui library of some sort so that they can be used by React developers. That is, if I have a button CLJS component, I would like to be able to render that Button using < Button /> or mylib.Button(_) etc.. in a React/js app file.
I have read this - https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-library - extensively but it's not quite working out. I've been using ":target :node-library" and I can get simple functions (that return strings/numbers, for example) to compile and work in my app, etc.. but it doesn't work for entire components. For example, my cljs button component takes in :
defn button [props & children]
but when I try to pass in these parameters (I call {lib.button({}, {})} in my App.js file), I get errors like "No protocol method IMap.-dissoc defined", because I'm trying to pass JS objects into CLJS-only functions, I believe. Not sure how to resolve this..
I can explain more on this if it would help clarify. It would also be super helpful if anyone had a reference demo project or any resources they could link me to.
I only have a few suggestions:
You can try to build a new sample project to consume your library with lein new figwheel myproject and use JavaScript interop to move one step at a time closer to the native JS way of using your library.
You can create an interface namespace that can consume JS objects and wrap these into Clojure data structures to sort out the protocol errors you're seeing, eg. functions that take a props parameter and pass down (js->clj props) to the rest of the code underneath.
For the authoritative source, check the Reagent docs, especially this: http://reagent-project.github.io/docs/master/InteropWithReact.html#creating-react-components-from-reagent-components
I've been looking to develop a method for loading modules and/or components into an AOT-compiled Angular 4 application and been stymied by a variety of solutions that never quite seem to get me where I want to be.
My requirements are as such:
My main application is AOT compiled, and has no knowledge of what it is loading until runtime, so I cannot specifically identify my dynamic module as an entry component at compile time (which is explicitly necessary for the 'dynamic' component loading example presented on Angular.io)
I'd ideally love to be able to pull the code from a back end database via a GET request, but I can survive it simply living in a folder alongside the compiled site.
I'm using Webpack to compile my main application, breaking it into chunks - and so a lot of the SystemJS based solutions seem like dead ends - based on my current research, I could be wrong about this.
I don't need to know or have access to any components of my main application directly - in essence, I'd be loading one angular app into another, with the dynamically loaded module only perhaps having a few tightly controlled explicit interface points with the parent application.
I've explored using tools like SystemJsNgModuleLoader - which seems to require that I have the Angular compiler present, which I'm happy to do if AOT somehow allowed me to include it even if I'm not using it elsewhere. I've also looked into directly compiling my dynamic module using ngc and loading the resulting ngfactory and compiled component/module, but I'm not clear if this is at all possible or if so - what tools Angular makes available to do so. I have also seen references to ANALYZE_FOR_ENTRY_COMPONENTS - but can't clearly dig up what the limitations of this are, as first analysis indicates its not quite what I'm looking for either.
I had assumed I might be able to define a common interface and then simply make a get request to bring my dynamic component into my application - but Angular seems painfully allergic to anything I try to do short of stepping outside of it alltogether and trying to attach non-angular code to the DOM directly.
Is what I'm trying to do even possible? Does Angular 2+ simply despise this kind of on the fly modification of its internal application architecture?
I think I found an article that describes exactly what you are trying to do. In short you need to take over the bootstrap lifecycle.
The magic is in this snippet here.
import {AComponentNgFactory, BComponentNgFactory} from './components.ngfactory.ts';
#NgModule({
imports: [BrowserModule],
declarations: [AComponent, BComponent]
})
export class AppModule {
ngDoBootstrap(app) {
fetch('url/to/fetch/component/name')
.then((name)=>{ this.bootstrapRootComponent(app, name)});
}
bootstrapRootComponent(app, name) {
const options = {
'a-comp': AComponentNgFactory,
'b-comp': BComponentNgFactory
};
https://blog.angularindepth.com/how-to-manually-bootstrap-an-angular-application-9a36ccf86429
As a fairly Microsoft-centric and predominantly back-end programmer, tackling all of these (cool) new technologies all at once has proved pretty daunting. I'm fairly pleased to say that I've got a lot of things wired together and that I feel as if i'm very close to breaking through one last hurdle to a point where i can finally begin to work and produce code efficiently in this brave new world, but there's a major obstacle I'm hung up right now. This is all new to me so i'll try to explain as i can:
I'm using VS 2015 and building up a DNX ASP.NET 4.5 MVC 6 web application. I've used NPM to install react, flux, and all manner of supporting modules. I'm working on my first fully-functional JSX screen which is using the flux pattern to load data and I'm receiving callbacks from my store when the data is loaded from an API service.
I love being able to use the require('xxx') syntax to chain the dependencies together, so I've formed that habit and i'm using browserify & reactify from my gulp task to manage the dependencies, gather all of the input files, and convert my JSX files to JS at, er, gulp-time i guess.
The issue i'm running into now is one that I never expected: when I use require() in a JS file to include a JSX source file that defines one of my react components and then attempt to mount an instance of that component using ReactDOM.render and JSX syntax, i'm receiving the following error:
Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components). Check the render method of xxx.
Up to this point in the other areas of my app I've always included the react components thusly:
ReactDOM.render(<MyComponent />, $("#reactTarget")[0]);
That has always worked. But now that I've bought in to the browserify world to chain these source files together, if i include the line
var MyComponent = require('./MyComponent.jsx');
...and then proceed to try to include an instance of the component with:
ReactDOM.render(<MyComponent />, $("#reactTarget")[0]);
I receive the error above. Now given that all of this is new and somewhat fuzzy to me, i'm not 100% sure that it's the browserify aspect of this which is causing the issue, but it sure feels like it.
I've also tried react.createClass, passing in the 'MyComponent' variable from the requires line, but no joy.
I have this mostly working but of course putting the data on the screen - in this case using react - is the whole point of the thing so, the fact that i now have a functional dispatcher, actions, stores and API calls is exciting but i can no longer simply compose my react components as i used to.
what am i missing here? There must be a way to combine these techniques and technologies but i haven't been able to find an example that equates to this particular combination.
Thanks in advance.
I sometimes wonder what life would be like if I were a smarter animal. I've just spent an entire day - a weekend day, no less, chasing down phantom solutions and alternate configurations until I wanted to cry when in fact my issue was that I'd left off the 's' in module.exports at the end of my component definition. That bloody 's' cost me years of my life, I suspect. That's what I get for not copying/pasting when I'm toying with tings I barely understand. I guess I learned a lot in the process, maybe I'll get those hours back over time.
Thanks to anyone who made an effort here, or even pondered it at all.