Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reaction-layout #148

Closed
aaronjudd opened this issue Jul 25, 2014 · 9 comments
Closed

reaction-layout #148

aaronjudd opened this issue Jul 25, 2014 · 9 comments
Assignees

Comments

@aaronjudd
Copy link
Contributor

Here's some rough thoughts on a possible new layout approach:

Create a new "component" collection:

@ComponentSchema = new SimpleSchema
  name:
    type: String
  component:
    type: String
  helper:
    type: String
  template:
    type: String
  position:
    type: Object

@Components = new Meteor.Collection("Components",[ComponentSchema])

Components types are UI helpers, that dynamically load templates, perhaps setting data

  • Textarea
  • Hero
  • Product
  • SocialBlock

This could allow for extending, customizing template (component) by cloning, changing the values of the components

You can have multiple templates for components

  • Hero -> Large Slider
  • Hero -> Static Text
  • Hero -> my custom hero template

You add to any grid page by:

  • Add new component
    • Choose Type
    • Choose template
    • Component Configuration Screen
    • Drag to position (and store position / priority)

For example:
Add a product

  • add new product, goto current product entry screen
    • grid settings
    • configure tags to display in grid
    • configure filters (gold, silver, new,etc)

Add a hero -> inline hero manager

The "productGrid" doesn't exist anymore, instead it's a generic layout grid, that injects the dynamic component templates into the grid

You wouldn't create a "productGrid" template, but you would loop through the applicable collection data and render each individual product grid item template and insert into a layout. You should be able to mix and match different components this way.

Is still a drag and drop interface, storing position or other layout in the component collection level.

I'm thinking that potentially the rendered layout would be a client layout collection + template

@aldeed
Copy link
Contributor

aldeed commented Jul 25, 2014

Yep, that's basically the same as I was thinking. 👍

I would add that this could probably be generalized to be a Meteor pkg that doesn't have any reaction dependencies and could be used in other projects. (Would be interested in using it myself.) What I'm thinking is that on the flip side of everything you already mentioned, the layout pkg could have an API providing the ability to add a component zone to any page, and to customize the appearance of that component zone, and to add custom filter functions. So one might do:

<div class="row">
  <div class="col-md-4">{{> pagePartZone "left"}}</div>
  <div class="col-md-4">{{> pagePartZone "middle"}}</div>
  <div class="col-md-4">{{> pagePartZone "right"}}</div>
</div>

Which sets up each area to accept configurable page parts (components). The app can provide a canEditPageParts: function (partName, userId) { return true; } option that decides whether the current user can edit a page part and returns true or false. If editable, you see the extra add/edit/remove stuff plus drag/drop between zones on the same page is enabled.

The app can also configure its own display logic functions, and a few could be built into the Meteor pkg, like isLoggedIn. Some of the generic types could also be part of the package: static text, static HTML.

@aldeed
Copy link
Contributor

aldeed commented Jul 25, 2014

I know there has been some work by others to create Meteor CMS, but I don't know the status of those projects. Azimuth, which seems to be maybe a bit neglected these days, has a concept of "blocks" which is similar to what we're talking about, but not as powerful or nifty.

@kifirkin
Copy link
Contributor

there also some new cms packages besides Azimuth I've just found.
This one looks great au-cmsinn, demo video is awesome 👍
and another one is Vector

@aaronjudd
Copy link
Contributor Author

As I mentioned to @spencern I think this could now just reside in Packages, utilizing the registry for the storage of the UI element information.

@kifirkin
Copy link
Contributor

I just found Orion.js. It looks like nice CMS solution 😄

@aaronjudd aaronjudd self-assigned this Jul 21, 2015
@kifirkin
Copy link
Contributor

Does anybody heard about Universe CMS? It appears in latest blog post from Meteor and looks awesome!
It will be opensourced in next month and they use ES6 and partially React.

Also I found very nice post about React plugins and Flux pattern ( Building Plugins for React Apps ) and it seems that Reaction uses similar approach for its extensions.

So maybe in near future we can use this kind of cutting edge stuff 😄

@kifirkin
Copy link
Contributor

I've just found nice package react-grid-layout. It will be the best option for layout editor maybe with this npm module as well react-ui-builder

@aaronjudd
Copy link
Contributor Author

@KEFIRCHIK that's really interesting, thanks! @mikemurray take a look..

@kifirkin
Copy link
Contributor

@aaronjudd I've just found another interesting project - landing-page-builder 😄

@aaronjudd aaronjudd removed their assignment Oct 9, 2015
aaronjudd added a commit that referenced this issue Dec 3, 2015
Changes that refactor the `ReactionCore.registerPackage`
implementation to a more flexible, and structured template
registry. `ReactionCore.registerPackage` moves to server.
package.registry is published to client.

These are not backwards compatible changes.

Updated documentation at docs/packages.md

Initial commit for issue #314

Strategic updates for Issue #273
Strategic updates for Issue #306
Strategic updates for Issue #305
Strategic updates for Issue #246
Strategic updates for Issue #183
Strategic updates for Issue #155
Strategic updates for Issue #16
Strategic updates for Issue #148

Resolves #53
Resolves #308
Resolves #178

*Remaining tasks*

solve undefined error
convert the rest of the payment packages
context sensitive widgets (context?)
update with detailed docs
(document all the existing "provides")
aaronjudd added a commit that referenced this issue Dec 3, 2015
##package-registry-refactor
Changes that refactor the `ReactionCore.registerPackage`
implementation to a more flexible, and structured template
registry. `ReactionCore.registerPackage` moves to server.
package.registry is published to client.

cycle = Core, Stable, Testing (todo: => correlates package semver)
container = combine multiple registry entries

These are not backwards compatible changes.

Updated documentation at docs/packages.md

Initial commit for issue #314

Strategic updates for Issue #273
Strategic updates for Issue #306
Strategic updates for Issue #305
Strategic updates for Issue #246
Strategic updates for Issue #183
Strategic updates for Issue #155
Strategic updates for Issue #16
Strategic updates for Issue #148
Strategic updates for Issue #146

Resolves #53
Resolves #308
Resolves #178
aaronjudd pushed a commit that referenced this issue Dec 3, 2015
replace bunyan-pretty with bunyan-prettystream, fixes #363
@aaronjudd aaronjudd added backlog and removed ready labels Dec 8, 2015
@aaronjudd aaronjudd self-assigned this Jan 27, 2016
aaronjudd pushed a commit that referenced this issue Jan 27, 2016
contains updates for the following related issues:
#671
#502
#148
@aaronjudd aaronjudd mentioned this issue Mar 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants