Is RactiveJS compatible with JSX?
I'm guessing some of the mark-up is not compatible. I like the thought of strong typing and being able to cleanly write the templates in JavaScript source. Maybe this is considered bad design?
No. React.js and Ractive.js have many similarities (for example, both work by constructing a lightweight virtual DOM in memory), but they have one very major difference - React completely rejects the idea of templates.
Which is to say that JSX isn't a templating language, it just looks like one! In React, if you have something like this...
<h1>Hello world!</h1>
...it gets converted to something like this by the JSX pre-processor:
React.DOM.h1(null, 'Hello world!');
In other words JSX describes functions, rather than templates. In Ractive, by contrast, Mustache templates are parsed into tree-like structures that can be transported as JSON.
Now, in the case of that example it doesn't really matter what process the original string goes through - it's still going to end up as an <h1> element in a browser somewhere. But it gets a lot harder when you start introducing arbitrary JavaScript which refers to this.state and this.props - things that can alter the fundamental structure of a component in React, but which have no meaning in Ractive.
Ractive might support templating languages other than Mustache in future, but JSX is unlikely to be one of them because they have such different approaches and design goals.
However there's a related issue here, which is being able to fully describe components in a single file. There's some ongoing work happening there - the most likely scenario is that we'll be able to describe components in an .html file (since you can use JavaScript and CSS inside HTML) rather than writing the template into your .js file.
Related
This has happened to me a couple times. Using something like an <img> tag, or <br>. Basically any HTML void element. Just today I attempted to use a <br>, and when saving got this:
Am I missing something?
Is there a reason for this?
Are void elements not intended for use in visualforce pages or components?
Or is this just flawed syntax checking?
Can be very frustrating at times, I ended up adding a false tag the other day because I realized it wouldn't be rendered and it was the only way to save my page...
P.S. I'm sorry if this has an easily accessible answer. I think I looked a reasonable amount, but not as much as usual before posting a question. Just couldn't even find search terms to get me close to something relevant.
Visualforce must be a valid XML document. Not HTML (which permits <img> without closing), not XHTML (because if you add any <apex:... tags not defined by W3C officially it's not a html document anymore, at least until it gets compiled and output becomes pure html0.
So you need <img> ... </img> or self-closing version, <img />.
In a way Lightning Web Components are even worse, self-closing doesn't work. Has to be explicit "end tag".
As to why... probably for easier ability to parse it as a valid document? I suspect they did it also for easier PDF generation.
This isn't exactly same topic but close enough I could find in reasonable time: https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_styling_doctype.htm
Having pretty complex angular application with many pages (states) and conditional sections that creates a lot of test scenarios I need to perform e2e tests. I'm tired of nested selectors like 'div.SomeComponent > ul:nth-child(2) > ... ' and so on even using BEM namings (especially when app is evolving and it's easy to spoil tests by little change of html structure).
The question is, would you guys opt for creating some dummy (empty) classes or data-* attrs just to simplify protractor (or groovy) selector at the expense of loosing semantics? What's the alternative?
To avoid changing your element definitions every time developers change the css and to avoid using long css strings to select your elements, you can try referring to them by other means (id, className, model, etc.). See https://github.com/angular/protractor/blob/master/docs/locators.md for examples.
My personal favorite is to use element(by.css('[ng-click="executeSomeAction()"]')) as this will most likely not change with any application updates. It also works for other directives as well.
As for testing applications with a high volume of pages and elements, it's nice to define your elements in a class(es) and then call them in the test spec as needed. This reduces the code in your specs and makes them easier to read. You may also want to create a separate file for actions/functions your tests perform.
Hope this helps answer to your questions.
Are there any simple ways to patch React to autoprefix styles, such that the rendered HTML doesn't differ on the client and server?
For example, is it possible to get
<div style={{display: 'flex'}}/>
to render to (ignoring data-reactid):
<div style="display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;"/>
In the specific case you posted, you may have to make a function in which you pass your style and it creates the correct styles. In cases where a simple prefix will work, you could use something like react-prefixr which just adds ms,Webkit,etc. to the style structure. If display:flex is not handled properly by react-prefixr, you can probably submit it as PR.
I've had the same issue and wanted an easy way to mixin styles. So I created a library that lets you use less/sass style mixins https://seogrady.github.io/style-mixin.
I've just today created a simple prefixing tool, react-prefixer. This handles prefixing possibilities for relevant browsers.
I say relevant because you call out display:-webkit-box syntax, which is basically Safari 5.1, its pretty non-existent these days. Additionally, it only adds the syntax needed, meaning you won't see the full string of styles as you showed ... based on browser support, it will either provide the prefixed version or the spec version, no need to clog up the markup with useless styles.
It's still pretty young (I coded it this morning), but maybe it can help.
I'm trying to create a directive to allow the user to navigate the page with arrow keys by section. But I also want to be able to have those sections be scattered around the dom, and to have this not break when stuff gets added and removed. I can think of several ways to do this, but none of them are satisfactory:
Create a directive with a controller that lets other directives register themselves (and unregister on $destroy). But this will be out of order if I add something in the middle later. Also, I've tried writing it this way, and it seems like way more code than necessary.
Whenever the user hits an arrow key, make an empty array, and $broadcast an event, with a callback for directives to register themselves on that list. Then, once that list is full, advance or go backwards on it. They (should?) come back in the order they're in on the DOM, but I'm not sure since this way seems crazy and hackish.
Mark things that are 'tabbable' with css, and write this the simple way in jquery, something like this: On a new click event, var all = $('.tabbable'), and then do the obvious with that. But I really don't want to do it that way, because it's not 'the angular' way. Not out of some sense of purity, but because I'm building this as part of a larger library of widgets, and I want this functionality to be accessibly to them.
So, is there any way for me to get the scopes of all directives of a certain type, without resorting to weird hacks, or spreading the logic out all over the place?
This is a good question. +1
First, finding all directives or nodes by type goes against the Angular way. The View is the official record in AngularJS, so directives should say what they do and do what they say. Coding some process somewhere to scan for DOM nodes and act accordingly is problematic for several reasons, not the least of which are separation of concerns and testability.
I'm glad to see you're looking at other options, but I agree that the other options you provided are sub-optimal for the very reasons you mentioned. But I have one more. This is one that I've used for a different application, but that required knowledge of scattered DOM nodes.
First, we create a service to manage the state of this component. It's simple. Let's call it SectionsService. Next, we create a directive to register sections. Let's call that section for simplicity. The section directive registers the DOM node's ID (maybe created programmatically to ensure uniqueness) with the SectionsService during its linking phase. Since the DOM is processed (mostly) in order, the nodes added to the SectionsService will also be in order. So the DOM looks something like this (irrelevant stuff omitted):
<div section>...</div>
<!-- other stuff -->
<div section>...</div>
<!-- other stuff -->
<!-- etc. -->
(Though out of scope here, it would not be very difficult to program it in such a way that the order wouldn't matter, but it'd be based on specifics of your app that I don't know.)
Next, you create your triggers, like an arrow key handler. On these events, you simply tell the SectionService to go to the previous/next node in the list. AngularJS comes with a service called $anchorScroll that can be used to emulate the browser's hash-based positioning we're familiar with. You could obviously also use a jQuery plugin to animate the scrolling if you wanted to.
And that's it! A very simply directive, a fairly simple service, and whatever trigger(s) you need. All told, I'd guess less than 100 lines of code including tests. All components are decoupled and easily testable, but still really quite simple. The view remains The Truth. The Angular Way is preserved.
And there was much rejoicing.
I hope this sets you on the right direction, but of course feel free to ask a follow-up question. We can also talk code specifics too if you'd like; as I said, they wouldn't be very complicated.
AngularJS services are singletons and can be required via dependency injection. You could have your directives require a state manager service and call incrementers/decrementers.
Alternatively, a little easier but more brittle, you could keep an array in $rootScope. It's more idiomatic "angular" (but not by much) than a jquery selector global, but probably not the best route if you're building a widget library.
Ui:include and xhtml based tag (the one with source elt) seem to be much the same for me. Both allow to reuse piece of markup. But I believe there should be some reason for having each. Could somebody please briefly explain it? (I guess if I read full facelets tutorial I will learn it, but I have not time to do it now, so no links to lengthy docs please :)
They are quite similar. The difference is mainly syntactical.
After observing their usage for some time it seems the convention is that fragments that you use only in a single situation are candidates for ui:include, while fragments that you re-use more often and have a more independent semantic are candidates for a custom tag.
E.g.
A single view might have a form with three sections; personal data, work history, preferences. If the page becomes unwieldy, you can divide it into smaller parts. Each of the 3 sections could be moved to their own Facelet file and will then be ui-include'ed into the original file.
On the other hand, you might have a specific way to display on image on many views in your application. Maybe you draw a line around it, have some text beneath it etc. Instead of repeating this over and over again you can abstract this to its own Facelet file again. Although you could ui:include it, most people seem to prefer to create a tag here, so you can use e.g. <my:image src="..." /> on your Facelets. This just looks nicer (more compact, more inline with other components).
In the Facelets version that's bundled with JSF 2.0, simple tags can be replaced by composite components. This is yet a third variant that on the first glance looks a lot like custom tags, but these things are technically different as they aren't merely an include but represent true components with declared attributes, ability to attach validators to, etc.