It's a collaborative tool to allow teams of developers and designers to move extremely fast from concept to real applications that work on the web and on Android and iOS.
It takes a JSON and outputs React code.
Designers and developers work together on the JSON code.
Pages defines a few basic blocks. The most important are:
- Horizontal and Vertical: they let you group other blocks. They also act as links between Panels or click handlers;
- List: it lets you repeat elements;
- Text;
- Image;
- Input: to build forms.
When extra UI/UX-related functionality is needed, developers can build a custom React block for all to use. This block then behaves like a regular block.
A Page take props like any other React component. This props act like a contract between your UI and your data. As long as you keep the contract, you can change its representation all the times that you want.
This is A/B (and even totally different concepts!) testing at your fingertips.
3) How do I integrate Pages output into my app, or, how does the prototype code migrate to a git repo?
Pages outputs React code. That is just text.
Currently, you copy it to your project by hand once you're happy with the UI. This is done through the Morph button. You will then commit it as any other file.
We're working on an auto-syncing tool that will remove that step altogether and automatically update your UI files in your app from Pages.
## 4) What tests (if any) are we automating? React components produced in Pages are very predictable.
Each page has a section called states. These mimic the props you would pass to your panel when connecting it to your data in your real application. Because in Pages we're using the same component that your application will use, you can be guaranteed that given the same props it will always render the same thing. We're improving our morphing process' test coverage as we write this.
Having said that, tests are still important and we have two concepts we will explore in the future:
- testing final component's React output by props (like what you would do today);
- testing by comparing screens to find visual regressions or misalignments automatically.
Outside of Pages, i.e., in our Panels applications, we leverage a combination of tape, proxyquire and sinon to test our reducers, actions and any other logic that our application may have.
5) Can we accept a new feature or update and then automate a rebuild/redeploy process if so, who/how does that happen?
Yes, see the answer to question 3.
Panels. Panels is a runtime built by us that lets you put together multiple views linked together in the same viewport.
We treat each domain as a separate application to leverage different entry points to information and processes at any given point in time. Despite us working explicitly with the URI like that, you don't have to and you can still benefit from the pattern. We can expand on this if needed.
This approach allows you to split your code in functional units.
Panels uses React to render your components. You can define a redux store that will be shared amongst panels of the same application. We're working on a mechanism for applications to connect between themselves in a secure manner. In the meantime, this can be implemented in user-land through a common bus or a service.
We use Redux because it gives us an extremely predictable state and allows us to both, develop very fast and easily achieve 100% coverage of our code because it doesn't get in our way with any framework artifacts. We normalise our state and use selectors to access it to be able to refactor it easily when we need to.
We use ES7 destructuring to achieve immutability in our reducers.
We don't need React router as Panels has its own integrated router that allows you to achieve more advanced features such as teleports.
We package our assets with a mix of rollup (to get one scope and less evaluation due to requires) and browserify (because it's very simple to understand and very efficient at what it does) but we also have mechanism to work with Webpack if needed.
For code spliting see question 6.
We only use classes in our React components when a component needs to have internal state or refs. Otherwise we use regular functions. Pages enforces this.
See question 4.
See question 4.
The Panels runtime exposes certain base packages (like React and Redux) that the apps can leverage. This helps keep each app's bundle rather small. You can also have a common vendor module across multiple apps that is only loaded once per runtime. Ultimately the bundle's size depends on how many external libraries are being loaded and how much code your application has. It also depends on which platforms you target, e.g., if you need to support ES5 or not, etc. We use uglify and our CDN gzips the assets even further to achieve smaller transfers.
Panels applications are totally compatible with NPM. You can require whatever you want. We're working on allow external requires in Pages. Most times your UI won't need anything external though.
We're not currently using hot-reloading but you could leverage it should you want to with HMR as our Pages produced components are stateless.
That depends on your needs. We've used the Ruby framework Padrino extensively in the past (Darío used to be a core contributor to it). However, we're currently building NodeJS apps because they fit better with our Panels ecosystem. We generally use some components of PillarJS (like the router) with raw node an example that built for pages. We're in favour of smaller functional units as far as it makes sense instead of monoliths.
7.12) How can we get AWS to host this web platform? Namely, how well does this integrate with AWS service platforms such as EC2, S3, the various database services, CloudFront, and Lambda to name a few.
Pages produce React code. Panels apps can run both, on the backend (and produce static HTML to get started with) and directly on the frontend (and do the whole setup and app resolution). You can host the assets wherever you want.
7.13) How easy/hard will it be to migrate from one middle tier/backend solution to another using this React?
Very easy. Pages produces raw React components and those work anywhere were React works.
Our components depend on usepages-blocks and whatever custom blocks you make. usepages-blocks are the basic blocks explained in question 1 and are easily interchangeable. The reason why we put that layer in between is to be able to abstract ourselves from the underlying implementation and be able to target different platforms, like react native without changing anything in your produced components other than the import.
Even better, because we're open source, our morphing mechanism is up for grabs if you want to have a specific outcome from the same JSON.
Thanks for reading :) Darío and Tom from UXtemple.
Have more questions? Reach out to us https://twitter.com/UXtemple or say hi@uxtemple.com.