I am learning the Entity Component System design pattern and trying to build a menu with it.
What I am building
The idea behind the menu is this:
Menu displays possible actions
When I select an action, I choose the first argument, then the second
When all arguments are selected, action is performed and I go to 1.
Egzample
Choosing action
o -> Open Browser
l -> Open Logs
pressing o to choose Open Browser action that requires two arguments: tier and project
p -> production
i -> integration
d -> development
pressing i to choose integration tier
1 -> project 1
2 -> project 2
...
pressing 1 to choose "project 1" opens the browser with "project 1" on the integration tier, and the action menu is displayed again.
My initial design
In my initial approach, I made each menu item an entity with different components.
E.g. project 1 is an entity with project component, integration is an entity with tier component.
I also have renderable and selectable components.
I have three systems: Selector, Action and Render. They "interact" with each other by modifying entities.
Init phase
The Action system adds renderable component to all actions during initialisation so that they get displayed.
Render system renders actions to choose.
Loop
Button press o
The Selection system adds selected component to "OpenBrowser" entity.
The Action system detects that action was selected and removes renderable from entities with action component and adds them to entities with tier component.
Render system renders tiers to choose.
Button press i
The Selection system adds the selected component to "integration" entity.
The Action system detects that action and tier were selected, so it removes renderable from tiers and adds to entities with the project component.
Render system renders projects to choose.
Button press 1
The Selection system adds the selected component to "project 1" entity.
The Action system detects that action and tier and project were selected, so it performs the action of opening browser, clears seletected components and attaches renderable to actions.
Render system renders actions to choose.
I am pretty content with Selection and Render systems. They are easy to understand, and they have a clear purpose.
However, the Action system requires three different aspects:
Entities with action and selected component.
Entities with tier and selected component.
Entities with project and selected component.
Entities with action (to add renderable at the end).
As far as I saw in the examples. Each system usually had one aspect (query of entities with and without particular components).
Is that a bad design? How would you redisign action system to use only one aspect?
Related
I have an Accordion widget that is connected to a datasource 'Projects'. I have a list of all the projects and their details. However, each record in the projects datasource has a string field called "Project Type" which can contain one type or several types (seperated by commas), for e.g "Field,Qual,Quant" etc.
The challenge I am facing is that I want to create another accordion that contains rows depending on the number of types of project. For example if ProjectID P23 has project type as "Field,Qual,Quant", then when I click on the accordion for Project P23 it must expand further accordion widgets based on the number of projects types, in this case, 3 more rows should be visible.
What I am thinking is that whenever I click on a Project row, it should create a datasource with 3 records depending on the number of project types. Then I can bind this data source to the subsequent accordion. However, the problem with that this will become a server-side call and cannot work synchronously. I want to do this on an onClick event of the first accordion so that results should be instant. And whenever the accordion closes, the datasource should get empty, so for any other project, it should be a dynamic process.
Any leads would be greatly appreciated.
P.S. I know App Maker is getting decommissioned.
I have trouble coming up or finding the boundaries of the so called "UI State".
Imagine the example of an issue tracker:
We have a list of "issue cards", which each contain:
A simple icon that represents the progress (i.e. open, closed)
The description text of the issue (a simple <p/> element)
A single Action button that changes d =epending on the state of the issue: "Assign to myself" or "Mark as done".
A button that opens a context menu (AKA right-click menu). This menu has a list of a variety of action buttons. Depending on the
state, some actions are greyed out and can not be clicked / or are
just not shown. Like "Close Case", if the case is already closed.
If you could categorize each of these items into UI-State vs. Application State, it would help me understand the boundaries.
More practically: How would you divide this little example application into containers and presentational components?
My interpretation: 1. and 2. are just presentational, 3. and 4. are stateful. Is this right? How would I structure this as containers and components?
Thank you very much!
All of listed examples are examples of application state, where UI is determined by persistent data that is received from the backend.
UI state usually refers to UI component local state that is determined by user actions, e.g. window position, active tab, unsubmitted form values, etc. Depending on the case, UI state may be lifted up and stored somewhere (persistent storage or URL) or be discarded.
if I want to implement this project I would act like this :
a component for managing all children components
a store to managing model, data and fields
a component for displaying icon and description text and button
a component for context menu
please consider that if you are using MVVM pattern, be sure that all responsibilities of actions are done by store and for changing some properties use observable fields
and if not use state in manager component and pass via proprs in children.
Let's say we want to create a new Task. We have 2 categories of information we want to collect from the user for creating a new Task: general params, action params.
To make it easily separated we are separating between them with tabs. so each gets its own react component, both stored in different react-tabs tabs.
In the parent component I have a save button and I want that at any given time, the user could click it to send the entire state from both the tabs' state to the server.
While I could forward event handlers from the parent to the children (as suggested by other questions on this topic)... doing it for each of the 20 controls (dropdowns, textfields, date time pickers) in each of them requires a lot of boilerplate code and seems unreasonable.
I'm looking for a best practice for this situation. Thanks!
My page is composed of hierarchy of classes and many reusable components. Multiple instances of a button component can exist anywhere in the page and on click they fire actions that populate different types of data in a common sidebar list component.
The requirement is to highlight the button that was last clicked to load the data in that sidebar list. Of course, it also means to remove highlighting from the previous button. Since these button can exist in different components, I cannot manage state in one parent component.
I am not able to find a solution in pure React. I don't want to use jQuery rather just stick to React. Note I do use Redux in the app though and would be fine with leveraging Redux state if required.
You should most definitely use Redux. You'll need to create a variable in Redux that gets updated whenever an action takes place that would require you to highlight the button on the page. Then use conditional styling for the button based on that variable.
I should create ExtJs4 app, which should have main menu, and each menu item should open a new page with different url, so if the user copies the url and pastes on other browser tab, the app should open that menu item.
I want to use ExtJs's recommended MVC architecture, but I don't know how I can use it with multiple pages/urls. All their examples are using single page.
One option is to reload the page each time when the user clicks on particular menu Item, so every url/menu item/page will be separate ExtJS app with it's MVC. But I think this approach has drawbacks, since the page will be reloaded every time and it's not good for performance. Also it's causes difficulties in reusing of components (common models, stores and views for different pages ).
So I would like to have one single app for all pages, but I don't know is there any solution to have different urls for different views (in my case: for different menu items).
Or is there another approach for such applications?
You would probably want to use a Viewport, and make the Center Region a Container.
The Center Region Container would usually have a Card or Tab layout.
When the user navigates to a new view (Component), you add that view to the Container, and make it active.
The big mistake is to change the URL first. You don't want to do that.
You want to navigate, and then set the URL if the navigation was successful. You should probably not use ExtJS's History component, as it is incorrectly implemented. I would recommend using HTML5 pushState.
You should make sure your navigation system works without changing the URL bar too.
I would recommend reading up on Navigation in Microsoft Prism, WPF, and Silverlight, as there is more documentation there, and then apply that to ExtJS.
http://msdn.microsoft.com/en-us/library/gg430881(v=pandp.40).aspx
Here is an example Navigation process:
call app.requestNavigate('contacts/5'); you would add this yourself.
you parse this fragment to:
navigationContext = {
fragment: 'contacts/5',
xtype: 'contacts-form',
parameters:{
id: 5
}
}
OPTIONAL: If using forms:
get active item from the navigation region (your center region). if exists, call confirmNavigationRequest(callback) . you will need to add this method or event.
if callback(true), proceed with the navigation. this allows the user to cancel a navigation, if say the form is "dirty"
END OPTIONAL
the easy way is to then create a new widget of navigationContext.xtype, add it to the navigation region, then call setActiveItem(widget). destroy the previous active item if it existed.
then call history.pushState(null, null, navigationContext.fragment)
then raise a 'navigatedto' event on the view, passing the context, and you can load the data from there.
More advanced scenarios include:
keep the previous component alive if you expect to return to it. add a keepAlive property and if true, don't destroy when add new components to container.
search the container and ask each component if it wants to handle the current navigation request (for example if a form loaded with contact-5 was already hidden in your navigation region, or if you want to re-use a form)