I'm new to om.next (and to clojurescript), and I have the following question. I can only get the root component to be invoked with the reconciler (i.e. have its query method invoked); every other component seems to need to be invoked with props and with om/factory. I think I'm missing something.
I am attempting to create a todo list app (100 points for originality!), with a filter to show completed/incomplete/all items. If my TodoList component is the root component, I can invoke it with query: [:todos] with no problem. I'd like to have a different root component, and also have a Filter component that goes through the reconciler.
Possible options I can see:
have multiple om/add-root! calls (this prevents us from having nested components that use the reconciler, and is not the pattern that I see in tutorials)
wrap everything in a global component and pass state down through props. But the examples make read a multimethod, which doesn't jive with this approach.
Is this possible? Thank you!
If you haven't already please take a look at Components, Identity & Normalization · omcljs/om Wiki · GitHub. This tutorial shows how to organize a multi-component application under a single root - and it should also make clear how read, mutate, Ident, IQuery, etc. are being used by each individual component to coordinate interaction with the one-and-only app state via the reconciler. The app-state is basically the application's database - using nested data structures inside a single Map.
React applications typically only have a single root component - if there are multiple roots they are typically organized by routes, i.e. one root per route (see also Top-level React Components — Medium).
Also: Om/Next: The Reconciler — Medium
The concept behind Om Next (and others such as reframe) is that there is one source of truth - your app state. With Om Next the UI of your application is made up of one (upside down) component tree. During rendering your app state is loaded into your Root component by Om Next interpreting its static query. This app state is received as 'props'. It is your job to pick these props apart and hand 'sub props' down the rest of the tree. You do this in the render method of each of your components.
So your second option is the way to go. reads are related to keywords that are in your static component queries. If you make sure that your state is in default db format, then in fact every read can be implemented the same way, making use of db->tree. Having a global component and making every read a multimethod are unrelated concepts, and thus not incompatible. In fact having both is quite idiomatic.
There are ToDo application examples already that you may wish to look at for reference: here and here.
One thing to note is that your Root component query will use joins to include the other components, so your query [:todos] does not look right to me. Something like [{:todos (om/get-query TodoList)}] would be better :-)
Related
I have 2 different types components. They both only use and contain an HTML5-canvas element, but need to show different types of data on a chart:
Component A (Only ever 1 of these)
Component B (0 to 4 of these)
Both components need the dateTime of the first data-entry from the two data-sets, but the dateTime of the last entry comes from their own respective data-sets.
Component A needs its first entry date from Component B.
Currently I do it like this:
Component B has the method that finds the date-limits from its own dataset. Using an Observer-pattern & Subjects, I broadcasts the returned dates through a service and into Component A.
The problem with this though, is that coupling suddenly becomes pretty tight. I can't initialize component A first, because it needs B to do its calculation first. Both components ideally should initialize and show/share their data simultaneously, and continue to do so. (E.g. If a user scrolls in one chart it should scroll all other components too, and so on.)
This is why I wanted an extra layer added on top of these components. A controller if you will.
I can't figure out what's best though:
A shared service that can take external data as input?
A container component? (Transclusion)
Another component, Component C, that A & B are children of?
As I'm still new to Angular 2, it's hard to tell which approach is best for future maintenance/development?
I'm being drawn towards creating another normal component as a parent, and have this component send and receive data to/from its children (A & B) as necessary.
I'm also uncertain as to what's "best practice" and if you can just use a component like an empty 'logic shell'. I've tried reading here and there, and I've found a lot, but I can't seem to get an exact answer to my question. It'll take time before I can comprehend all this knowledge and answer it myself, so I'm hoping someone could give me a helping nudge, thanks.
PS: I should add that my angular application will be a child-component in larger application, and will get its data from some other parent comp.
Why don't you put your logic into services?
You can also set up service hierarchies by injecting sub-services into a parent service.
If your logic is not UI / interaction related, you should put it into reusable services. If your logic is UI related, you could set up a parent component acting as a mediator between A and B (acting on their respective input/output parameters)
Whatever you do, it is a good idea to keep concerns separate.
Both A and B should not need to care about other components needing their output. Angular has Input/Output parameters for that.
Don't put some generic datetime calculation stuff into components. Make it reusable through services.
Keep coupling loose by introducing interfaces and injections.
Update:
Services should only use injectable constructor parameters, so you should pass your input using methods (or setters, but that is less expressive).
To pass arbitrary JSON objects, you could utilize any parameters. However if your json follows a certain structure, you could define an interface.
public doStuff(input: any): any { }
or
interface IMyDataContract {
dateField: string;
}
public doStuff(input: IMyDataContract): any { }
I've been playing around with this for a while now, and I think, I've - almost - cracked it, but I am still not fully satisfied with my solution.
So, what I want to do, is having a piece of content, a list of items, which would have two views: The standard HTML one, so people can view and edit it; and then a JSON endpoint for other services to consume.
First I thought it's a simple matter of creating two JSP scripts to render the content:
/apps/my-stuff/components/list-page/html.jsp
/apps/my-stuff/components/list-page/json.jsp
However the Apache Sling DefaultServlet seems to be rather ignorant of the json.jsp script.
As a second attempt, I created another script, in /apps/foundation/components/primary/cq/Page/json.jsp which will be actually called, and renders the page, as I expected. However there are a couple of worries/questions regarding this:
First of all, why is this being honoured by the system, and not the one in the more specific place?
The documentation states, that to find the appropriate renderer, first sling:resourceType will be inspected, then sling:resourceSuperType and then, only as a fallback will jcr:PrimaryType checked. However I think this is rather: jcr:PrimaryType, then the DefaultServlet, and then all the other things.
Most worryingly however, I have to admit, this is rather generic, so it'll break all the contnet with jcr:PrmaryType = Page, so that could have some side-effects.
A solution could be creating a new type: ListPage extends Page; and then create a renderer for that in /apps/foundation.... However I have this bad feeling, that might introduce other problems.
So my question is two fold: What is the proper way of doing this, and/or what am I missing from the way the URL -> script resolution is working in AEM/Sling. (Because it seems to be slightly different that described here and here.)
(Obviously I am trying to keep the default JSON renderer for other pages, as that might be needed for other things in the page. I am not even sure, changing this one page won't break the UI for this particular page...)
However the Apache Sling DefaultServlet seems to be rather ignorant of the json.jsp script.
Have you tried renaming your JSP like so: "list-page.json.jsp"?
If you're using AEM 6.3, you should look at Sling model Exporters. They allow you to automatically register a servlet against your Sling Model (that you can create to model your list content). That servlet can generate a JSON representation of the model for you using Jackson.
If you're not using AEM 6.3, I would suggest you create a servlet registered against your resource type and use an additional selector.
#SlingServlet(
selectors = "json",
resourceType = "my-stuff/components/list-page",
methods = "GET")
More information on Sling Servlets can be found here.
I have gone through David Nolen's basic Om tutorial but I am still a bit confused about the difference between application state and component local state. When cursors are referred to is it referring to one or both of these too?
As I understand it:
Application state is the "global" state that all components in the component tree can access, through cursors. This is the state that your application is in and basically what is being rendered by Om. So, for example, if you are writing a chat program, the application state would contain a list of users in the conversation and all of the messages that have been sent, or whatever.
Component local state is state that is local to a single component and cannot be seen outside of this component. It is set either by passing {:init-state } to build, or by implementing IInitState and returning a map from init-state - or both (in this case, they are conj'd together). David Nolen recommends that local state should only be used for transient state, such as if the mouse is currently pressed in a drag/drop component and that all other state should be application state. That is, if you have a tab widget, the currently selected tab should be set in application state (not local state!), but if the tab is being dragged to a new location, the current position and mouse state would be (temporarily - until the drag operation is complete) be stored in component local state. Things like core.async channels can also be stored in local state (though I've also stored them (and seen others do the same) in shared state and additional data - see below for details on both)
Cursors only apply to application state and are like windows into it so that components far down the tree can access only the data that they actually need to access.
Application state is always accessed through a cursor (app in the tutorial) and modifying application state is done through a cursor - both om/update! and om/transact! take a cursor as their first argument. You can also set the application state atom directly with reset! and swap!, but David recommends against this as by doing that you lose out on some of Om's more advanced features (like being notified of change deltas).
Local state can be received through IRenderState or by accessing it directly with om/get-state. You can set local state with om/set-state! and om/upate-state!. All three of these take a component backing object (owner in the tutorial).
There is also a third type of state in Om: shared state. Shared state is passed to om/root using the {:shared ...} option and can be accessed from any component in the tree under that root, using om/get-shared. The difference between this and application state is that application state is narrowed down through cursor paths - that is, sub components may not have access to the entire application state - while shared state is always accessible. Also, modifying application state causes the component to be re-rendered while shared state does not trigger renders.
As an aside, there is actually a fourth type too - you can pass additional data to components through build using the {:opts ...} option. This is data that lives outside of the Om/react lifecycle - that is, its immutable data that you can access from a component, but the component does not manage it in any way. This seems to be most useful for configuration data.
I'm After several days learning angularJS through converting my standart JS app to a ng one.
I was wondering about this simple scenario:
I have a global function called fb_connect(),
it can be used from any page (or any controller if you like) to make a facebook-based login.
This function makes a simple http call and receives a JSON object contain data to move on (display a pop up, login, etc...)
I read that I can define a Factory or a Service for my app and use it in any controller, which works fine.
So, I created a fb_connect factory function.
The problem is that now, in every page (every controller), I have to define that fb_connect in the constructor of every controller - for example :
function welcome($scope,fb_connect){});
What is the proper way to do this kind of actions using Angular without having to define these functions each and every time in every controller?
Thanks
Setting up factories and services is all part of the dependency injection system of Angular. Using that system is great when you need to create things that depend on other injected things. It's a big tree of dependencies. It's also nice for creating singletons, such that everywhere in your code end up using the same instance of some object.
It sounds to me like neither of these benefits apply in your case. I'd suggest just not using Angular's DI for it. You have some function defined globally, just call it directly and skip the DI. There's nothing wrong with that.
Of course you say it makes an Ajax call, so doesn't depend on the Angular $http service?
Your two options are:
Declare the function on the $rootScope
Inject it as a service
My advice is to go with making it a service. The whole purpose of services is explained in the Angular.js docs, just like this quote:
Angular services are singletons that carry out specific tasks common to web apps... To use an Angular service, you identify it as a dependency for the dependent (a controller, or another service) that depends on the service.
As you mentioned in your question, you'd prefer to not define the service in every controller you wish to use it in. With $rootScope you'll be injecting that also in every controller. So really it's a question of which you prefer, although to answer your question, the proper way of using a factory or service is to inject it into the controller you wish to use it in.
You can always put it in the $rootScope
myApp.run(function($rootScope, fb_connect){
$rootScope.welcome = function(){
};
});
I have a tree control in my GUI (with naturally lots of GUI/platform specific functions to handle the nodes).
I have a data model with its own complex set of nodes, children, properties etc..
I want the tree to display a representation of the model, be able to send messages to the nodes inside the model and be told to redraw itself when the model changes.
But I don't want the GUI code to need to know the details of the model's data types and I don't want to pollute the model by linking it to the GUI classes.
I can't get my head around how the controller is supposed to do this and what functions it should provide?
(this is in C++ but that shouldn't matter)
GUI "controls" don't quite fit neatly into a model-view-controller pattern because they typically have their own internal model rather than accepting a reference to one. If the control is structured that way, you'll need an adapter class that "data-binds" the control's internal model to the underlying data model.
This can accomplish something similar to what model-view-controller would, except that the adapter class plays the role both of a view hookup component (updating the GUI from the data model) and a controller (interpreting GUI events into model actions).
Qt provides a group of classes for model-view programming. You can hook a tree view to a filesystem model, for example, and neither directly know anything about each other (except a pointer to the model in the view).
Your requirements are:
Tree displays representation of model
Nodes in tree can send messages to nodes inside model
Tree redraws itself based on model changes
I don't know exactly what kind of data you're working with here, but a hierarchical model is a fairly simple thing. I'll take it as a given you know how to iterate hierarchical data and populate a tree view.
Your controller should have member function(s) for sending messages to the model. The parameters should be a model element and the message you want to send. This way, the UI is completely unaware of how the message gets to the element, but can get the messages through.
The last requirement is more tricky, and depends on a few things (e.g., the lifetime of the controller, application architecture, etc.) I'm going to assume the controller lives as long as the tree view does. If that's the case, then your controller should provide a way to set a callback on model changes. Then, when the controller changes the model, it can callback to the UI without being aware of the UI.
i think your troubles start with an unfortunate choice of words. the 'control' thingies doesn't have anything to do with the 'controller' in MVC. that's why some GUI libraries use other names (widgets is a common one).
your 'tree control' is the view, not the controller. it should be tied to the GUI, both for display, and to get GUI events and turn them into 'tree events'.
the controller gets those 'tree events' and does the necessary modifications to the model. that's where you couple the 'action' with the 'response'.
First Solution: You can implement a "Subject observer" pattern between model and view, with model as the subject and view as the observer. Whenever there is a change in the state of model, it can fire a event to all the observers those are registered, they can update themselves.
Second Solution: Introduce a controller, which registers with model as observer. Upon receiving a event for update from Model, it can update the view. Even you can decouple view from controller using one more subject observer pattern between controller and view
Third Solution: Use MVP pattern. Model view Presenter. This pattern used whenever there is no much computation in controller i.e., job of the controller is just to update its corresponding view. Here controller becomes Presenter.
You need a controller that sits outside the display widget but has the state of the tree (in MFc there are CTreeView/CTreeCtrl classes - there is a similiar separation in Qt) the tree controller handles all the data storage and calls redraws on the tree widget.
Changes in the tree widget get sent to the tree controller - so this controller needs to know about the gui functions.
The model will need set/get functions for all the relevant parameters for the nodes. But these can return simple types so aren't dependent on the gui.
Updating the view form the model requires sending a message, if you don't want the model to know about your gui messaging the best you can do is register a callback function (a void pointer to a function) from the tree controller - and call this to do an update.
This update function can then query the model for the changes.