Skip to content
This repository has been archived by the owner on Oct 2, 2018. It is now read-only.

[Strategize] Modularity #208

Open
3 tasks
ferndot opened this issue Nov 7, 2014 · 7 comments
Open
3 tasks

[Strategize] Modularity #208

ferndot opened this issue Nov 7, 2014 · 7 comments

Comments

@ferndot
Copy link
Member

ferndot commented Nov 7, 2014

Objectives for this discussion:

  • Decide upon an effective modularization strategy.
  • Write a wiki page explaining that strategy.
  • File bugs for the implementation of the strategy.

All comments are welcome!

@ferndot
Copy link
Member Author

ferndot commented Nov 7, 2014

I have been implementing a basic modularization strategy without defining it. This could cause problems for Firetext, so I have created an issue for us to discuss it.

Current concept

Parent

Definition: The parent is the core process and layout of the app. It serves as a hub, connecting all of the modules and components.

Components

Definition: Components are bundled sections of the app. They are inserted directly into the main layout.
Possible implementation: <component data-name="foo"></component> where foo is the component's name. This tag will be replaced with the contents of the component file.

Modules

Definition: Modules are independent and self-contained sections of the app. Modules, unlike Components, are loaded in <iframe> elements, and communicate with the parent through messages.

Please feel free to propose different ideas, or change the existing ones.

@twiss
Copy link
Collaborator

twiss commented Nov 7, 2014

Possibly web components are applicable here. I've never used them though.

It would be great if components

  1. Could be used in Firetext without having to rewrite everything
  2. Could encapsulate the difference between desktop and mobile, as I proposed in [Strategize] Firetext on Desktop #203
  3. There were already a few ready-to-use components useful to us

@ferndot
Copy link
Member Author

ferndot commented Nov 8, 2014

@twiss: web components sound great. Mozilla has a cross-browser polyfill for them here: http://www.x-tags.org/.

IMO we should still use our custom system for Modules. IIRC, <iframe>s offer performance and security benefits. In fact, I believe that Firefox OS uses frames extensively for that purpose. What are your thoughts?

@twiss
Copy link
Collaborator

twiss commented Nov 8, 2014

Sounds good to me. Candidates for modules:

  • Editor
  • File system
  • UI extensions, such as sharing documents or so

@jackd1
Copy link
Member

jackd1 commented Nov 8, 2014

Note that some filesystems are capable of working in a worker thread, so that might be a possibility.

@jackd1
Copy link
Member

jackd1 commented Nov 8, 2014

E.G. the file system api

@Ryuno-Ki
Copy link

@twiss: web components sound great. Mozilla has a cross-browser polyfill for them here: http://www.x-tags.org/.

FWIW: Google's approach is called Polymer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants