I am studying Omniture/Site Catalyst on my own and have the following query:
Scenario where eVars can be used as a props variable.
Scenario where props can be used as a eVars variable.
I have a basic understanding of eVars and Props and as per my thinking the 2nd scenario is invalid and we can't use props in place of eVars.
Is there any scenario where eVars can be used as a props variable.
Props and eVars are only really interchangeable if you're looking to only record the actual value of something. They are pretty much different and not interchangeable in most other aspects.
One major thing a prop can do that an eVar can't is that you can enable pathing on a prop but not an eVar. But also, they have a handful of mutually exclusive items they can be correlated/broken down with, as well as some mutually exclusive available metrics.
Also, one or the other may be better for segmenting, depending on what you are actually trying to do.
Here is a link that gives more details:
http://helpx.adobe.com/analytics/kb/compare-props-evars.html
One thing to note that is out of date on that page is that you can now enable pathing on a prop yourself.
Scenario where eVars can be used as a props variable-When you expire evar on hit then it act as prop
Scenario where props can be used as a eVars variable-Only when you are interested to know Instances
Props have one value per page, eVars have one value per session [1]. You use props when you want to see how a value changes from page to page (pathing), you use eVars when you are interested in the value that was set last in the session (i.e. to identify an internal campaign).
Plus, what Crayon Violent said.
[1] Actually you can set different conditions at which eVars expire, so they might have different values in one session. Still, usually a new value overwrites the previous one in en eVars (hence no pathing for eVars).
Another way to look at it from a reporting aspect is props will tell you where users are going while eVars also let you know where they're coming from. We'll set an eVar on a directory page and not on the detail page - in the reports, though, you'll see that eVar against those detail pages...which can tell you which directory page (or other) the user came from (or...converted from, hence the idea of a conversion variable). The synonymous prop on the other hand only records visits to that directory page (just a traffic variable).
Related
can I use Use state instead of redux?
Can I Manage all the state by use state ?
This question has a long and complicated answer, but I would suggest the first port of call would be reading up on the redux docs about how you might want to organise the state within your application.
TL;DR, it entirely depends on your situation, take a look here
Both are valid, but both have cases where they are better to be used, for example if you have a state you want to manage one level below, and is not used by other components on different hierarchy, then passing the state and it's handler as a prop is the better solution.
But some cases are more complex and require a lot of passing down of a prop through the components until it reaches the child that actually uses it, and. the parents of that child do nothing but pass it down, that is a smell of bad code.
Here it is beneficial to have it in a global state where the child can access it directly, without needed all of its predecessors to pass it down as a prop (also known as prop-drilling). Another case where this is useful is when multiple components need to access the same state, in different part of the system. It would be much cleaner to have it stored in a global state available for every component that requires it.
TL;DR, depending on your case, one solution is better than the other. Assess your situation case-by-case.
I'm asking this to make sure I understand the concept. In UI Router, they recommend you use nested states as much as possible. However, it seems when you do that, you can only have 1 controller per state/view. Which in most cases is fine. However if you need two or more controllers on a state/view then it seems that Multiple Named Views is the right solution. Because it seems that you can actually have different html elements or divs controlled by different controllers - if necessary.
So for example on a search results page, you could have different elements or divs on the page controlled by different controllers.... is this what Multiple Named Views in UI Router is designed for?
It seems for more complex pages, like a search results page, Multiple Named Views is a better solution than simply having nested states... because you could have an Authentication controller, autocomplete controller, search controller - all being responsible for different areas on the page. I'm not even sure how you accomplish something like that with nested states.
So am I understanding this correctly?
I think you are confused with the fundamental definition of views and states. That being said, your understanding (to your own problem statement) is correct.
In ui-router, the fundamental principle it is making your app into a state machine. The basic definition of state machine is that, at any point of time, only one state can remain active. This is actually quite useful and a good design pattern - in a sense that you can define what your machine (or app) should do (or how it should behave) when it is in a clear defined state. Good for debugging too.
However, it doesn't mean that in a single state, the machine cannot do multiple things. It can, as long as in that state, its job is to do multiple things. Let's take a movie booking app as an example.
Disclaimer: this is not exactly a real state diagram but lets just use it for discussion purposes. Image courtesy of Google Search
Now all the blue rounded rectangular boxes are states. Meaning, when the user uses the app, at any point of time, he/she will be in one of the states - he must, or else he is not using the app.
Now it can be quickly realized that if the user is in SeatsChoosing state, he CAN'T be in other states - not PromotionSelection, not Payment, or other states, at the same time. He can go to other states (called state transition), say PromotionSelection, but only after he has done choosing. The point is that no more than one state is active here aka no Parallel States. Only one at a time.
While it only can be one state active at a time, but that doesn't mean machine cannot perform multiple tasks at a single state. Take the SeatsChoosing state as an example. In the SeatsChoosing state, multiple tasks are performed, including loading the movie, fetching the location, display the schedule, etc. But the user will experience all these things, only if he is in SeatsChoosing state. The point is you can have multiple tasks executed at the same time in a single state, as long as your state definition allows it.
And that's is exactly what ui-router is achieving. At any point of time at your app, you can only have one state active. The nested states are still a single state by itself, its just actually a node traversed down the state machine - and when you are down to that node, only that node is active. No parallel states are allowed. For the same token, it doesn't mean your state cannot do multiple things at one time. That's where named views are for. For a state, you can have different views that has different clear defined contexts (view), which all of them fall under the same domain (state) as a big umbrella.
Now lets go back to your Search Results problem statement. How do you define your state, and how do you define your views? This is entirely up to you, but just make sure if you are using ui-router, you adhere to the state machine's rules - aka no parallel states but allows parallel tasks. So if you define a state is a page that does multiple things - authentication, autocomplete, etc, then yes multiple named views is the correct way and not nested states. But if you are separating search and search results as two different domains, then, maybe nested states will be better.
There is no right and wrong answer for this, just a matter of design decision.
Hope that helps.
One pattern I've seen recommended is to use selectors to where possible to hide the shape of the store. That way if you need to update the shape of the store, you should be able to get away with only updating your selectors, and not other parts of the application.
However the same problem arises with the use of models within the state.
As one of many examples, let's assume I'm building a file system in Redux. I have a list of files which can either be a directory or a file.
My store might have a fileList property which contains an array of file ids as well as a files object which maps fileId to a file object.
Let's say I have a list of files and I want to, depending on whether it's a file or directory, have a different Item component (i.e. DirectoryItem and FileItem).
One way to achieve this is to do something like:
{
files.map(file => {
file.type = 'directory' ?
<DirectoryItem key={file.id} ...file /> :
<FileItem key={file.id} ...file />
)}
}
(or I could create a higher-order FileListItem component, for example, that does the check and renders either the DirectoryItem or FileItem)
However this might not be ideal because now my component needs to know the structure of the file object. I might want to add a different type of object (i.e. a shortcut file or shared file) and might decide that a type property isn't how I want to represent my data anymore. As such, I'd need to go and update all my components, etc.
If I were doing this in Backbone, for example, I would've probably chosen to define an isDirectory() function on my model, however that doesn't seem to be the Redux way of doing things.
One possible solution I can think of is creating a FileUtils helper class which exports an isDirectory method and takes a file object as a parameter.
Another option will be creating an isDirectory selector which takes a file id as a prop, doing something like:
(files, props) => state.files[props.fileId].type == 'directory'
If I were to create the selector, I suppose I would need to create a higher-order component to call the selector from.
Just wondering if either approach is recommended in Redux? Am I missing another approach that could help solve this issue?
The functional way of doing things simply prescribes tearing the method off of the object and calling it a function.
The recommended way to call it is to instead of having a this, simply pass a regular parameter. This is not a requirement. You can just use call or apply. That may seem real strange in js, but this may change soon with a new :: operator.
Now, you can give this function anything you like to help it get its data.
In your example
(files, props) => state.files[props.fileId].type == 'directory'
You pass it state (naming mistake there) and props and then use this info to come up with an answer. But you could instead choose to pass it a directory entry object. No need to go fetch it from state.
Note that this makes it very close to a method.
isDirectory = entry => entry.type === 'dir';
Now, because it's not getting state, it isn't selecting anything from state and is therefore not a selector.
However, it's plenty functional in nature. There really is no need or use to make life more complicated than that. Adding a higher order component or trying to shoehorn our problems into a more Redux-y way of doing things is needlessly complicating matters.
Selectors are recommended for selecting state so state usage is not tied to state shape. It's an abstraction layer, separating your mapStateToProps from your reducers.
Selectors are now considered part of the Redux Way, but that wasn't always true. And so, at your discretion, being informed of why something is done the way it is, you can then choose to not use it.
And, at your discretion, you can choose to substitute the current trend with your own version. It is highly recommended to do this, of course after consideration of alternatives.
Often the best solution is the one you come up with yourself. Being the most informed about your problem domain, you are uniquely qualified to formulate a matching solution.
Those who have developed great ideas that all of us feed off of and get inspiration from will probably move on from their viewpoint when something better comes along.
There isn't (and probably shouldn't be) a sacred paradigm. Everything is eligible for reconsideration. Occam's razor dictates that the simplest answer is most likely the right one.
And Redux is very much about simplicity. So to do things the Redux Way is mostly about doing things the straightforward way.
The Problem:
I'd like a single ui-router state to match the following urls:
#/.../update?id
#/.../update?username
#/.../update?customerId&sandwichId
If/when the 'update' state is active (it's a routed component), the component's controller knows enough to expect which params will be there (via a provided array of Strings that should/will match whatever query params are in fact present).
Current Solutions (none of which I'm 100% happy with)
I could just leave the url at '#/.../update' with the implicit understanding that I cannot navigate to that url from anywhere but it's parent state, and just pass in its primary key fields as a component binding. The drawback obviously being if I just type the URL in my browser, it will not have enough information to load.
As per an example I found here, I defined my 'update' state with single query parameter: pkKeys. I then define pkKeys upon my state transition to be the entire query parameter string I desire. This effectively achieves what I am looking for. However, typing this just doesn't feel right:
#/.../update?pkKeys=username=test
Moreover, it looks ugly on the more complicated situations:
#/.../update?pkKeys=customerId%3D3ae2e6eb-3bf7-42f8-a09c-9c690c8dbe15%26sandwichId%3D2cb6d513-06a3-4aa4-93bb-e53d279d95cb
Ideal Target State
Ideally, I'm looking for a way to configure my state in a way that matches the above patterns of urls. I did not have much success with $location service, but something tells me that has something to do with it. It appeared to me that $location.search() was cleared whenever $state.go( ... ) was invoked.
Thanks for any help in advance! Happy to elaborate on anything that might not be clear. It's a rather unique problem set I find myself in here...
On Further Research
For reference, I'm using Angular UI Router 1.x. I have found they have the notion of dynamic parameters, which seems to nearly solve the problem I am encountering (see the GitHub issue for this change). However, where this fails me is the state configuration still expects you to list the dynamic parameter's name. As my query param names are data-driven, the set of names is not a finite set. So I need dynamic parameters...with dynamic names.
I have two components, contact form, and input.
At this moment i pass onChangeEvent from contact to input as is described in many tutorials and its works fine - input update his owner state.
But there is way to pass 'this' from contact to input by prop, or context and then I can update owner state without passing onChangeEvent - but is this a good idea?
Is there another option to update owner state without passing onChangeEvent?
I believe you could technically do it, as a React component is a regular javascript object in the end, so you could pass it as a prop.
However, that's not a good idea in general, for various reasons:
It tightly couples the two components together. If you ever want to reuse the input component in another place, you'll need to pass in the exact same state.
Linked to this, it allows manipulation of the internal state of one component, by another component, which is a violation of good OO design.
You are right however, that things tend to become quite verbose when working like this. They also become hard to reason about when one has more complex trees of components passing props and change handlers between them.
One solution to the problem, is employing the Flux design pattern, and namely it's Redux implementation.
In Redux one has a single piece of global state, a plain object, of which components see pieces (sub objects). Components receive this state as props, and just render from it in a simple fashion. There's a set of actions which transform this state, and any component can issue such an action, as a result of user interaction. There's still the concept of "state", but it is reserved for truly local things, such as the state of a form before pressing the save button etc.