I am using angular2-meteor.
When I try to pass a value between two components (when the value change in the first component, create an event in second component and use this new value), I have two ways right now:
One way is meteor way: using this.autorun and Session.get.
Another way is angular2 way: using Injectable service with EventEmitter.
Which way should be prior? Or is there any other better way? Thanks
Now I used angular2-meteor a while.
Although the angular2-meteor tutorial has no example so far about using or choosing Angular 2 service or Meteor Session.
But I feel angular 2 takes the lead in the front end, while meteor makes reactivity easier and also handle all back end things.
So I went with angular2 way using service to share between components. And service is very powerful like #todd-w-crone said.
If anyone has better answer, I will switch to accept that one.
I find it practical to create a new service called App.states.ts which is accessed globally and mimics Session (get / set).
I commonly import this service to all necessary components to get or set new value such as User.status, company.profile, lastProduct, etc.
Since this service is #injectable it can also make use of other services, in case a value hasn't been set already.
This allows me to ask for a variable in a component appState.getLastModifiedItem(), then in app.states.ts I'll write this function to pass this.modifiedItem or either:
Request another service item.service.ts to fetch data
Call another function with itemCollection.findOne({...}) and return such value.
You can configure Mongo queries as you want and either store static data in appState or keep subscription items in appState.
Do take into consideration that all subscriptions handled by an #injectable within a component are imported by such component. Be wary of conflicting subscriptions between components/services.
Related
When I generate resources, methods etc. using "for_each", how can I make a deployment depend on them? Terraform requires a static list as value for "depends_on"
I think what you are looking for here is this (somewhat hidden) reference in terraform documents about triggers
I was facing the same issue (using for_each to create gateway methods, integrations) but was not able to reliably trigger api-gateway redeployment, until this...
... or removing the .id references to calculate a hash against whole resources. Be aware that using whole resources will show a difference after the initial implementation. It will stabilize to only change when resources change afterwards
This allow us to do the following in triggers
triggers = {
redeployment = sha1(jsonencode([
aws_api_gateway_resource.gateway_resources,
aws_api_gateway_method.gateway_methods,
aws_api_gateway_integration.gateway_integrations,
]))}
By removing .id (and thus not needing to reference each.key, or any element in the dynamic list) you let terraform decide if the hash of the file changed. If it did it will redeploy, if it doesnt change, then no redeploy required :)
Reference https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/api_gateway_deployment#terraform-resources
Look at the comments on 'triggers'
I have an app using React + Redux and coupled with Firebase for the backend.
Often times, I will want to add some new attributes to existing objects.
When doing so, existing objects won't get the attribute until they're modified with the new version of the app that handles those new attributes.
For example, let's say I have a /categories/ node, in there I've got objects such as this :
{
name: "Medical"
}
Now let's say I want to add an icon field with a default of "
Is it possible to update all categories at once so that field always exists with the default value?
Or do you handle this in the client code?
Right now I'm always testing the values to see if they're here or not, but it doesn't seem like a very good way to go about it. I'd like to have one place to define defaults.
It seems like having classes for each object type would be interesting but I'm not sure how to go about this in Redux.
Do you just use the reducer to turn all categories into class instances when you fetch them for example? I'm worried this would be heavy performance wise.
Any write operation to the Firebase Database requires that you know the exact path to the node that you're writing.
There is no built-in operation to bulk update nodes with a path that is only partially known.
You can either keep your client-side code robust enough to handle the missing properties, or you can indeed run a migration script to add the new property to each relevant node. But since that script will have to know the exact path of each node to write, it will likely first have to read/query the database to determine those paths. Depending on the number of items to update, it could possibly use multi-location updates after that to update multiple nodes in one call. E.g.
firebase.database().ref("categories").update({
"idOfMedicalCategory/icon": "newIconForMedical",
"idOfCommercialCategory/icon": "newIconForCommercial"
"idOfTechCategory/icon": "newIconForTech"
})
So there are several parts to this question.
The 2 example endpoints (in simplest form):
user/{id}/profile
movie/{id}/info
I expect to create 2 controllers (UserController & MovieController).
How do I implement a view area before controller name?
Both of these are what I would consider a view. Therefore I would like to append a "view" in the url before the controller, as both controllers ONLY supply views. I later expect to also have a user controller in a different place that does NOT return views.
However, ALL my endpoints should start with /api/.
i.e. I want this:
api/view/user/{id}/profile
api/view/movie/{id}/info
But how do I register an area (/view/) while using "custom routing" (i.e.: httpConfiguration.MapHttpAttributeRoutes())? Any examples of this I couldn't find?
Where should I put versioning?
The client is an app, and will require versioning, so that we can make changes to the methods without breaking old versions of the app.
We are unsure where it would be best to place the versioning, and how the placement affects the development of new versions (if it does so at all?).
Possibilities:
1. api/v1/view/user/{id}/profile
2. api/view/v1/user/{id}/profile
3. api/view/user/{id}/profile/v1
version the whole API. This would upgrade the whole API to a new version, even if we only required a single method/endpoint to make an app-breaking change.
Are there any advantages to this that I am not seeing?
version the area. Same as above, just slightly fewer controllers affected.
version the method. Seems like the simplest, as only the single changed method is affected. But the url is very ugly.
Does anyone have an example of versioning in an MVC or Web Api structure that doesn't upgrade the whole API, but still keeps a somewhat nice structure in their URLs?
I ended up using https://github.com/Microsoft/aspnet-api-versioning as suggested by NightOwl888.
1.
Made my 2 controllers extend another controller with a const field that defined the routeprefix that they should share:
protected const string RoutePrefix = "api/view/v{version:apiVersion}";
...
[RoutePrefix(RoutePrefix + "/user")]
2.
The placement of the /v1/ doesn't matter with this Library. And allowed for either updating the controller or individuals methods, as seen fit per case basis.
I am building an app with React + Redux + Immutable JS and am running into some architectural problems. To illustrate I will use my user record as an example. The user object is an Immutable Record, defined in the user reducer. Now I would like to define some methods for this user (for example, isCurrentUser(userId), which would return a boolean and can be called on any user instance). From what I gather, the state should simply be plain objects though (reference: How to put methods onto the objects in Redux state?)
However, since this method wouldn't change the state of the application it doesn't make sense to use the typical Redux flow either. Is it acceptable for me to define methods within my Immutable Records, or should I be defining some helper methods in a separate JS file. Or maybe there's something else I haven't thought of?
You can create a new layer called 'services' and put this methods inside it. So, you can have a services/UserSession that is used like.:
{ isCurrentUser } from './services/UserSession'
isCurrentUser(user)
Does it help you?
I am creating a mobile app that will connect to a zendamf implementation to retrive certain information to store and display to the user.
There are multiple php classes on the gateway to handle things like users, Orders, Products etc.
Therefore I would have a package called remotehandler with classes under it, remotehandler.orders remotehandler.product, remotehandler.users. Which would mean for each class I could do the following:
instead of creating a connection for each type of call I want to make lots of times I was thinking that it might be better to create a wrapper class for each call family I.E
Users
createUser - calls a php function to create the user
DeleteUser
UpdateUser
after some searching I came accross this post
http://flexdevtips.blogspot.com/2009/05/using-flex-and-amfphp-without-services.html
which shows how to deal with netconnection in code. but it is written if you are planning on making a single call.
Does anyone have any ideas or example on how I could turn this in to a class that would allow me to specific different source(php class functions).
Thanks
JaChNo
Simply expose a property on your Class (let's call it source) as a getter/setter pair that, when set, changes the source of the RemoteObject.
However, I find it is better to have a different Service Class for each return type I expect, because I can then mock the service and just drop in the mock when I am working on things that don't require a live connection to the database (such as skinning).