i want to try new React api calls server components. I don't find any information about how can i start project with server components. In source code example i find
react-server-dom-webpack/plugin
must i use it? and why we need it in all which use server components? I found it here - https://github.com/reactjs/server-components-demo/blob/main/scripts/build.js
it doesn't have any documentation on npmjs.
Can i just add .server.jsx prefix to my component and start use them?
Related
In an application called Backstage, there is a component that I have found called "DependencyGraph" which I like the look of and want to use something similar in my react app: https://backstage.io/storybook/?path=/story/data-display-dependencygraph--bottom-to-top.
Does anyone know of something similar to this which I could install and use within my own react app such as an existing package or something?
I can see the DependencyGraph component basically builds an svg diagram based on the different "nodes" and "edges" you give it but hopefully there's an easier way to do it than creating my own custom component to render svg images with paths, etc...
I've tried installing the #backstage/core-components module which contains the DependencyGraph component but the react version it uses is outdated. I also don't want to install everything else that comes with the #backstage/core-components package.
I'm new to React and JS, and working with react-csv-viewer.
It works as expected and I can build and deploy it on a local server. But I do not require this, I just want to integrate the app as a component of a static HTML page.
I've tried following the process listed on the React tutorial for this, but I have trouble understanding the build process and how can I achieve this.
All I wish to achieve is to be able to use <CsvViewer /> provided by the author, possibly like this
const rootElement = document.getElementById("root");
ReactDOM.render(<CsvViewer />, rootElement);
and get the viewer app rendered at my HTML file, without building and deploying the viewer app on a (local) server.
Will appreciate any help or hints in this regard.
You can add React as it was shown in the tutorial you linked. The downside is that, you can't use JSX syntax (as it should be converted to JS during build time as it's not recognized by browsers as so).
Here is a post explaining how you can do so without transpilaton steps.
https://codepen.io/alexkrolick/post/react-without-a-build-step
Alias React.createElement, and call it to create components.
e.g.)
const h = createElement // convenient alias
// Instead of
<div className="foo" />
// create an element like so
h("div", { className: "foo" })
For more info on how that works, check out the official documentation.
https://reactjs.org/docs/introducing-jsx.html#jsx-represents-objects
But I really doubt anyone writes React code that way without a transpilation step in real life.
Would creating a separate site/page with React be a problem by chance? You can check out ParcelJS to easily create a React site if you aren't familiar with transpilation.
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
We are looking at writing a new app using React but will need some existing Angular Directive that are specific for our business, for example a modified Angular Date Picker for example. There are many components so we won't be able to rewrite them all.
I am wondering if anyone has experience or knows the effort or feasibility of this?
The only article I've managed to find on this so far has been. Most resources I find mention going the other way from an Angular App with added React. http://softeng.oicr.on.ca/chang_wang/2017/04/17/Using-AngularJS-components-directives-in-React/
There's a library called angular2react that makes possible reuse angularjs code inside react components. You can see if it fits your needs. :)
I have written a simple demo app showcasing how to achieve it: react-angularjs-bridge
The basic steps are as follows:
Create a react component that is going to host the angular component in the DOM. This component should always render a simple html element (eg. a HTMLDivElement) so that react does not get confused when reconciling the virtual DOM with the real DOM.
After the react component was mounted componentDidMount, create a shadow root under the rendered HTMLDivElement and initialise the angular application under it. This will ensure that the angularJS component is encapsulated and is not affected by the react application and vice-versa
Click here for a demo. Check how the react application styles do not impact the styles of the angular component.
Independently of Angular, ref is a way to go: it gives to access to an underlying DOM node and the ability to manipulate the DOM inside that node in any way you like, including AngularJS. Your changes will stay - at least until react clears the component altogether.
You can create a ref in react by
<divOrAnyOtherDom ref={((el) => {this._elem=el;}).bind(this)}></...
(for the full description and alternate ways to the same end see here: https://reactjs.org/docs/refs-and-the-dom.html#callback-refs)
Anyway, as you now have a DOM node, you can start working with it, i.e. adding angular to the mix inside componentDidMount. Sadly, this is not really obvious - here's a way that has worked for me in the past (moduleName needs to be a module you have put in place already with your logic):
let baseElement = angular.element(this._elem);
let templateElement = angular.element(templateSource);
angular.injector([ 'ng', moduleName ]).invoke(function($compile, $rootScope) {
let cmp = $compile(templateElement);
scpe = $rootScope.$new(false);
scpe.varname = whateverYouHave; # point is: you can set scope variables
cmp(scpe);
baseElement.append(templateElement);
scpe.$digest();
});
Now you have angular inside the DOM node react gave you.
(I've taken this from a slightly different integration: Vaadin to AngularJS, but the principle is the same: Vaadin, just like react, gives you a DOM node. When you're interested in the full code: https://github.com/akquinet/vaangular/blob/master/vaangular/src/main/resources/de/akquinet/engineering/vaadin/vaangular/angular/NgTemplate.js)
Plus: For any callbacks from the angular component, you'll likely have to use setState et al.
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.