I have a "simple" question about Angular 2 internal DOM manipulation. Is Angular 2 using Virtual DOM, Incremental DOM or what. I have been looking all over the internet to understand what Angular 2 uses for DOM manipulation internally but I can't seem to find it.
I understand how they create components and how they allow us the developers to use the encapsulation strategy we would like.
I understand it uses zones to detect change and observables to apply change but did they come up with their own logic for internal DOM manipulation or are they manipulating on real DOM?
React has virtual dom, Ember uses glimmer, other frameworks use incremental dom. What does Angular 2 uses?
TIA.
Whenever we create a component, Angular puts its template into a
shadowRoot, which is the Shadow DOM of that particular component.
Doing that, we get DOM tree and style encapsulation for free, right?
But what if we don’t have Shadow DOM in the browser? Does that mean we
can’t use Angular 2 in those environments? We can. In fact, Angular 2
doesn’t use native Shadow DOM by default, it uses an emulation. To be
technically correct, it also doesn’t create a shadowRoot for our
components in case no native Shadow DOM is used.
More: http://blog.thoughtram.io/angular/2015/06/29/shadow-dom-strategies-in-angular2.html#understanding-shadow-dom
Related
We are using a traditional CMS that also offers API (Rest & GraphQL) to expose content on top of page builder capabilities, I want to understand:
How to know if my traditional CMS is also a true Headless CMS?
Can a headless CMS offer Page management capability or it can only
create the content pieces that can be tagged & exposed via API to
multiple channels?
If that is the case, then doesn't my front-end logic needs to take
care of a lot of things while rendering the page to understand which
content will go first & which one last?
Wouldn't this create a tight coupling between CMS & Front End (be
it in the form of taxonomy)?
Is there any real advantage for Content authors in headless CMS as I
believe they will lose the drag & drop / WYSWYG features that is common
in traditional CMS?
Thanks
Your CMS is truly headless only if the content is completely separated from the context it is displayed in, that is, you should be able to change the destination of where the content goes, and have your front end determine where and how to layout the content. If your CMS controls or entirely owns this, it is no longer headless. If you're using contentful, this can be made easier by their JSON responses that come in a very structured order. In this case you are providing some context, but it is not anywhere near a dependency. These responses from the API are editable. So you can easily change this dependent on the destination of the content.
Yes it can, Headless CMS's provide enough metadata (ID's Slugs etc.) for you to create variable routing on your web application. Contentful also has the capability to attach SEO information with new content types. Keep in mind, a Page can be a content type that holds other content types. In this sense, your pages should be able to accept generic component objects, which will render a specific layout for each. Then that layout is backed with content from contentful.
As far as understanding which goes first, this can be inferred by the structured JSON response that comes from contentful or other headless CMS's. So it isn't much work to layout the order of things correctly. Here is an example from their docs. If your entry is a single entry that contains other types of content, they come in the order that they appear within the headless CMS, which means editors can shift things up and down as they choose.
https://www.contentful.com/developers/docs/references/content-delivery-api/#/reference/entries/entry/get-a-single-entry/console
to put it shortly, yes. You have to do a larger amount of work on the front end to accommodate this, but there are benefits long term. Once you have a suite of content types and layouts, eventually, the editors can become autonomous.
The advantage for editors is more of a safety for developers. Because they are locked into only editing content, it is impossible for an editor to make mistakes regarding style, positioning, or responsiveness. They also do not need to learn new technologies if you decide to change the front or backed of your web application. All the editors can see is the content magically appearing on the website. If they want to change the layout of a section, they don't need to contact you for these types of changes, so long as you've implemented that layout for a component. It keeps everything uniform, and allows for teams to effectively manage releases for new content.
I was reading several style guides on using react on the server side, and they all (rightfully) seem to suggest that components should be a pure function of states and props.
That begs a question that if I were to use a DOM API, say window.innerWidth or canvas.getContext(), which is the best place for doing so according to the react + flux philosophy.
componentDidMount will only executed in client side, you can place browser-specific code there.
But if it's not enough, my recommendation it's use DefinePlugin if you prefer webpack as your build tool.(I believe there are plugins provide same feature if you prefer other build tool)
new webpack.DefinePlugin({
__CLIENT__: true
})
And use conditional statement to judge whether the code is executed in browser environment.
Im a relative newcomer to GWT.
Im working on a GWT application, where I have a lot of table data that is to be displayed on a page and a redirect to a different service which happens when I click on each cell's data. Currently what is happening is that the entire HTML(with all of the cells' hyperlinks) is being created on the server side and returned as a big string which is rendered on the client side. As you can imagine, it doesnt scale well. I need to make this redirect more dynamic. Can anyone suggest how I could link the DOM elements with GWT code to make this happen?
Regards
In GWT there is Ui Binder
Declare your all ui on client side and hit the server only for the valuable data.
Browsers are better at building DOM structures by cramming big strings of HTML into innerHTML attributes than by a bunch of API calls. UiBinder naturally takes advantage of this, and the result is that the most pleasant way to build your app is also the best way to build it.
So avoid passing html through the wire.
I have an idea to add a edit-layer to website as a Plack middleware.
Explanation: let's say, we create a website, based on some framework and templates and CSS (requesting it like /some/page). Now we could create a middleware so that every request to pages starting with adm (like /adm/some/page) shows the same page, but adds a layer for content editing. So we could easily look and use the page as visitors do, but with double-click on block-level element we could modify or add content. So middleware should bind certain block-elements with certain events (double-click) and set handlers too (with some Javascript library).
For now it is just an idea and i have not seen such approach in any CMS. I am looking for hints and ideas and examples, how to start and implement such system. I hope, there is already done something like that.
You could do it, but I don't think you want to do this. My understanding is that Plack::Middleware's are supposed to be generic, and implementing a CMS as a plack middleware limits its re-usability, and its out of place, there is no inherent connection between a middleware and a CMS.
See these as examples Plack::Middleware::OAuth, Plack::Middleware::Debug, Plack::Middleware::iPhone, Plack::Middleware::Image::Scale, Plack::Middleware::HTMLMinify
It would be trivial to add a middleware filter to insert a form in your html based on /adm/ or /admin/ or whatever ... and mapping the url to the dispatch would highly depend on the underlying CMS model/view/controller framework, which is why frameworks such as Catalyst, Mojolicious and other already provide this feature
See http://advent.plackperl.org/2009/12/day-23-write-your-own-middleware.html
Basically, I think this is a job for a view/controller of your application, a plugin, not a wrapper for your application (middleware)
I know my explanation is lacking but hopefully you catch my drift
I've been thinking about this recently and I don't know a really nice and tidy way of creating a mobile version of an existing or new MVC2 website/app.
I think the easiest way would be to just use a different stylesheet depending on whether a mobile was detected but sometime you need to change the view content too if you have massive inline images everywhere or for other reasons.
What is a good approach for this? Is there a way of theming fairly easily in MVC2?
Well MVC is just your server-side technology, what you should ask to yourself is "what is the best practice to create a mobile web site, regardless of the server side tech".
In my opinion, creating a well-formed and semantic (x)html is the first step. As you say, the most logical thing to do is create different style sheets for different media types, and you're right.
As for the problems you mention, like inline images, consider this: are those images content or presentation?
In the first case, they should be present even in the mobile version.
In the latter, they are defined in the style sheet, so you can simply avoid them in the mobile css.
The only exception I can think of is when you want to provide different functionality on mobile, or if you're forced to, i.e. on pages that rely heavily on JS and those scripts wouldn't run on mobile browsers. In this case, you might want to create different versions of those pages and serve the appropriate version based on the user agent.
Check the source code for NerdDrinner. They've implementated a MobileCapableWebFormViewEngine class which inherits from base WebFormViewEngine class. The MobileCapableWebFormViewEngine uses the HTTPContext to decide which View to render in the client. This'll make more sense when you see the source code