I'm trying to find a way to import the Prismic.io javascript kit in my Angular 2 project.
Is there a way to do so ? I tried to understand their Angular2-starter but it's not documented to do it on an existing project.
I want to know if there is a way to import node modules directly into Angular2 ?
Thanks in advance !
You need to be more specific, what does it mean import modules directly into angular 2?
First, to have common ground about modules:
Modules are a core feature of javascript, either natively in ES6 or using bundlers (e.g WebPack, SystemJS, etc...)
Importing a modules is not related to Angular 2
As for Angular 2, if by using directly you mean being able to inject service via the dependency injection then this is just a configuration operation done in angular.
In the case of an external, 3rd party, NON Angular library you might want to wrap it with an angular service which is then injected.
The starter project you linked to does so, it defined a prismic-service class that wrap the original prismic library so you only work against the wrapper class.
You can extend this class to support more features as you go.
Some notes on extending 3rd part libraries in angular 2 vs angular 1:
AngularJS (1) developers approach 3rd party libraries with caution. Since AngularJS has an internal change detection mechanism that Angular has to manage, execute and control. Any 3rd party library that modifies data that directly or indirectly effects the UI must also trigger the internal change detection in angular.
In Angular2 change detection is triggered by generic async operations such as events, user interactions, etc... Angular does not manage it directly, it is triggered automatically as if it was magic. This is possible due to the help of Zones which is both a concept and a library. Angular implements NgZone.
Basically it means that you can use prismic directly or as a wrapped angular service, it doesn't matter, it will just work.
I guess that most of your questions will focus on integration, which is how to take the data from the API and make a UI out of it.
The prismic Development kit provides a REST API for retrieving metadata about UI elements and data that they contain.
The client (in a SPA, like angular 2) needs to display actual UI components from the metadata.
In other words you need to build Angular 2 components that correspond to the components in prismic.
A common JavaScript library that builds a UI from prismic REST API data will not work here. It will generate HTML code that is not part of the angular application and does no participate in change detection, lifecycle hooks and routing.
All components in angular must be compiled first, at the bootstrap or at build if offline compiler is used.
The minimal approach is to get the HTML markup from the server and inject it into an angular component acting as a wrapper. This allows control over the lifecycle of a page and used for routing, page transition animation etc...
The starter project provides such a wrapper called DocumentPage. The DocumentPage has logic to download it's content (via route parameters) from prismic and display it as raw HTML. See here
The html markup retrieved from prismic is NOT bindable and you can't apply change detection and expressions in it. If you split it into chunks you can apply some angular magic in between.
So, it's quite simple actually, the starter project is a simple wrapper around the prismic framework in both API and UI. Angular has a small part in the application as it acts as a simple wrapper/container. The actual content is driven by prismic. I don't see benefits using angular with such approach, it doesn't do any harm but it's not really an angular app.
A proper angular2 prismic app would be built upon pure metadata representation of components which are implemented in angular as angular components. It is quite an advanced app that requires dynamic component creation as well as advanced routing implementation with lazy loading (to introduce new components on the fly).
Related
We are looking to use KeystoneJS in a large project and we want to be able to customise the Admin panel. There's a nice example of how to do it here, and I've been reviewing this PR to the project. Although the example looks as if it would work for us, I don't understand the logic behind it, that is, what we would need to implement to make it work, what the possibilities and constraints are.
Is it the case that when you use the Keystone NextJS app (which is good for us), if you add a folder /admin/pages the Keystone app will look there and use those custom admin pages instead of the regular ones? I'm assuming we have full access to the rest of the app, the controllers, the DB from these pages as well....
I also noticed that JedWatson notes in https://github.com/keystonejs/keystone/pull/1019 that
Note this lacks SSR support, and I didn't put as much effort into the examples, but it's otherwise (I think) identical in functionality.
Does it lack SSR support just for the admin part, or does adding custom admin pages somehow affect SSR support in the rest of the app? (SSR is the reason we're using next)
Thanks for any info.
There are two api for custom pages, one is pages option in the admin-ui app constructor and 2nd is part of hooks api in keystone constructor.
pages: this one is legacy and only adds custom pages, it does not overwrite the existing list pages in admin-ui it only hides them if not properly configured. usually the Dashboard is visible and all lists are listed there.
hooks: this is new and expected to add more customization options, unfortunately my PRs are stale and they are not the spec keystone core team would want to add. this also does not removes any pages.
admin ui runs as react app built or loaded using webpack config. that is why there is no ssr support. even though the example use a custom admin directory but that not loaded by nextjs component, it is loaded dynamically using webpack server mounting the admin-ui react app
if you really want to have ssr, you can use some learning from closed PRs which were used as POC long ago. but that would be overkill as the admin-ui has many more updates after that.
hooks/pages have access to core limited set of access, there are some access based on React context, provider and consumer hooks. You can use react-apollo hooks as there is already provider wrapped at root of react context. you can also make use of react router hooks, they are upgraded to latest version. it has no access to server side context or controller. (not sure what you meant by controller)
Can you tell me more about the relationship between the two? I want to (for example) write a little tool which plays audio files on my raspberry pi. Would I then do the player and the players interface completely in React, and then just connect to node in order to get the actual files?
Or, more generally but the same thing, if I would want to write an application that does certain things (writes files, records audio, changes system settings etc.) that would all be done in nodejs, but if I want to have an interface I would use something like React?
I am a bit confused, but I hope this question is valid!
Node and React can be used together.
There is even the MERN stack that helps with that:
MERN is a scaffolding tool which makes it easy to build universal apps using Mongo, Express, React and NodeJS. It minimises the setup time and gets you up to speed using proven technologies.
See: http://mernjs.org/
But you can use React with any other Node framework, not only with Express. React can work with any REST API so whatever you use to build a REST API can be consumed by the frontend written in React.
Some other options include: Hapi, Restify, LoopBack. For more see:
http://nodeframework.com/
from the official React Documentation React is "a JavaScript library for build user interfaces". In very watered down terms (and I mean watered down) React could be thought of as a templating library (please don't shoot me for that).
What I've learned about React is it is more like the "V"iew in MVC. It provides you a way to present the user interface using JavaScript and JSX. With the little I know about from various tutorials, I really like working with React.
Yes, this two thinks can work together, I am currently working at such project. I will point out main think here. That is where you put your routing. Does it goes to Node.js server or to React Router. This is important because it defines where you application logic should be.
ReactTS is a scaffolding engine for React on ASP.NET Core. Very powerful, and very fast - will generate your entire application with a single button click. You can also customize the templates. Check it out here... http://bssdev.biz/DevTools/React-Turbo-Scaffolding-Free-Download
Hope I'm not being to general but: I have been tasked with the job of "rejuvenating/modernizing" a monolithic Java EE (JSF/CDI/EJB/JPA) app. Since the requirements state that it should support multiple clients, I have split up the code in a server (JAX-RS interfaces) and a client part (not yet done)
The server is pretty straightforward but I'm wondering about the UI part. Nowadays (hope I don't sound too oldskool) various Node JS spin-offs seem to be popular but I'm under the impression that they have the most value to offer in the "scalable server" section. Does the various Angular/React/Node framework have anything to offer for the client if you have something more complex than a single page app?
It appears to be a really hard time to pick a UI technology nowadays. Sure, the server/DB part which contains most of the business logic are pretty future-proof but still, one would like to focus on one UI technology. There are various jQuery-based frameworks like Kendo, Vaadin & co etc. One option would be to stick with JSF + ICEfaces/PrimeFaces and just work with the REST interface. And then there is JavaFX which looks nice but the future looks a bit uncertain.
So. If the backend is not going to be Node JS, does Node JS have anything to offer for the UI part that can't be done more easily with other frameworks and does anyone have other insights on the UI layer in general. Predicting is hard, especially the future ;-)
Node.js is a way to run javascript on the server side, not client side. That said, npm (nodes package manager) or its wrappers (like bower) are quite often used to manage the client side dependencies - which is very useful to have.
Angular and react (among others) are client side javascript ui frameworks to help make writing ui much nicer. Neither depend on the backend being written in node.js and can work with any rest api (or other server side apis) - or no api at all if that backend injects all the data the page needs into the page itself.
Electron, which combines NodeJS and Chromium (render Process).
https://electronjs.org/
Formerly known as atom shell it was created by Github, it is the core of the Atom Editor, VS Code, Slack app, and a ton of “thick client” applications. https://en.m.wikipedia.org/wiki/Fat_client
There are several implementations which allow you to use Node.JS modules on a client-side (ie. web browser). You can then use html/css and call Node.JS modules directly from your DOM which is used to implement UI.
I'm most familiar with NW.js which I've used couple of times. Others would be for example Electron or AppJS
I am new in React js. Previously i used JSF framework for building the web application. According to my knowledge in JSF actually what does is, from the server side it will generate the html code for the corresponding JSF tag and send it to browser and display it. If you are using JSF 2 the corresponding front end html portion can replace through AJAX also.
I think the same thing we can done through React framework. In react JS you can generate the client side html code from server and it will render in frontend by using some Javascript Engine (Nashorn Javascript Engine).
So in both case the working is almost same (The response created from the server). Now a days everyone talks like the React JS is a high performance framework. So can anyone explain how it provide better performance?
I repeat i am new in React JS
I believe performance all depends on the implementation, you can get both React and JSF to do the same thing. JSF came before React, and React in my opinion adopted many concepts of JSF anyway. React has not made any breakthrough that hasn't already been there with web templating engines since JSF 1.2. JSF is a templating technology which React recreates with Javascript.
For a mobile device its better to get the complete HTML to save on battery initially... both React and JSF can do Single Page Apps (SPA) to use Ajax and update only a portion of the DOM while the User is interacting with the application.
For pages with user interaction, JSF will send the Javascript needed that will interact with one DOM directly, for React it will use its shadow DOM and the browser DOM.
Both can define custom UI components, JSF speedier sends the rendered HTML directly to the client, while React will have to build it using the client computer cpu.
We can compromise performance for faster UIs, changing UIs faster, software engineers vs scripting folks salary. For any large scale, I'd prefer JSF because of reusable Java libraries in microservices, AI, Machine Learning, Android, and other things that has a JVM. For the UI, maybe we can let a scripting person whip up a UI in React while we focus on the bigger solution?
Internally, ReactJS uses a virtual DOM that will be "mapped" to the "real" DOM. In React you give your variables as state or props to the react component. React uses a special algorithm to detect changes in the components state or props and will only rerender the affected parts by synchronize the virtual with the "real" DOM.
JSF is an MVC framework that takes advantage of server side rendering and makes use of many markup files.
React is a library for building graphical interfaces for applications according to the SPA (Single Page Application) model.
The strength of React lies in its ability to update the dom very quickly because it has a virtual one.
The final app can fit all in a single file.
As said React is only a library, it is not productive to use it alone to create an application.
(Similarly JSF is just a spec, without Rich Faces, Prime Faces, Omni Faces, Boots Faces and 3rd parts libraries it would be difficult to create an application)
In the SPA model, the session is stored with the user, the backend is just a set of services that are called up by the frontend.
There is a first authentication call which produces a token (JWT) which is stored on the client side and which will then be used to
invoke the server's (stateless) REST services. This is how the server can understand that it is the same user.
The key information for the session is stored on the client side, this fact already makes you understand that the server is relieved of the task of
keep in memory the sessions of all connected users.
In practice, when the user interacts on a SPA application, what travels is the data, not the markup since all or most of the markup is already on the client,
this implies a nice saving in data transfer. The REST paradigm uses json to structure the data to be exchanged with the client.
A json object (Javascript Object Notation) that arrives at the client is a string representing a Javascript object, The latter offers native functions
to convert Json strings to Javascript objects and vice versa. React has nothing more to do than use this object to "go there to that specific point" and update the displayed data
and it does it very quickly.
JSF requires the presence of its own and third-party Java libraries on the server side (configured as a part of an Application Server) so it requires configuration time
higher and has a rigid scalability compared to a React application ready for deployment which consists of only javscript files (even one would be enough)
which only needs a web server like Nginx to run. It is easy to understand how easily this last solution is scalable since the configuration is reduced to zero.
To scale, just create a nginx docker image with our React app inside and we are ready to move from the development pc to the various cloud solutions on the internet
ready to replicate our image across multiple on-demand instances.
I´m learning kohana for the first time and need to know some basic facts about the mcv principle.
Up until now i´ve only used Javascript frameworks (ext, openlayers etc) which are referenced in the headers of html pages. The classes are then extracted and used in applications. I can have as many separate applications referencing one Ext.js framework installation as I like.
Kohana,as an mvc framework, is obviously different, but which purpose does it fullfill? Is it used to create web applications inside the Kohana installation ie. one web application...or is it used to create an endless number of applications? As far as I can see, one downloads the kohana framework, and adapts/extends the framework to make an application..e.g. a web cms. Am I on the right lines?
cheers,
Rob
The Kohana framework is typically used to build a web application. You would normally use one Kohana install and work with that to make a web application.
You could if you wanted, install Kohana centrally in somewhere like /usr/share/Kohana
Then you would move the application folder out and set the update the paths in index.php to the right places (there is a system path, module path and application path).
MVC allows is a design pattern for separation of business logic (model), controller (uses the model to get data and pass it to the view) and the view normally is what is outputted to the browser (HTML). You can read more here
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Yes, typically each web application has its own copy of a library. So, one copy of Kohana is extended to one web app.
MVC is a pattern that is common in web frameworks. It leads to better code reuse and lose coupling among different parts of the app.