Here's how I approached this:

**Camera**

My camera is an entity like any other, which has attached components:

1. `Transform` has `Translation`, `Rotation` and `Scale` properties, in addition to others for velocity, etc.

2. `Pov` (Point of view) has `FieldOfView`, `AspectRatio`, `Near`, `Far`, and anything else required to produce a projection matrix, in addition to a `IsOrtho` flag used to switch between perspective and orthographic projections. `Pov` also provides a lazy-load `ProjectionMatrix` property used by the rendering system that's internally calculated on read, and cached until any of the other properties are modified.

There is no dedicated camera system. The Render System maintains a list of `Pov`'s and contains logic for determining which one to use when rendering.

**Input**

An `InputReceiver` component can be attached to any entity. This has an attached event handler (or lambda if your language supports it) that is used to hold entity-specific input processing, which takes parameters for current and previous key state, current and previous mouse location and button state, etc. (Actually, there are separate handlers for mouse and keyboard). 

For example, in an Asteroids-like test game I created when getting used to Entity/Component, I have two input lambda methods. One handles ship navigation by processing the arrow keys and the space bar (for firing). The other handles general keyboard input - keys for exit, pause, etc, restart level, etc. I create two components, attach each lambda to its own component, then assign the navigation receiver component to the ship entity, an the other one to a non-visible command processor entity. 

Here's the event handler to handle keys that are held between frames that gets attached to the ship's `InputReceiver` component (C#):

 void ship_input_Hold(object sender, InputEventArgs args)
 {
 var k = args.Keys;
 var e = args.Entity;

 var dt = (float)args.GameTime.ElapsedGameTime.TotalSeconds;

 var verlet = e.As<VerletMotion>();
 var transform = e.As<Transform>();

 if (verlet != null)
 {

			/// calculate applied force 
 var force = Vector3.Zero;
 var forward = transform.RotationMatrix.Up * Settings.ShipSpeedMax;

 if (k.Contains(Keys.W))
 force += forward;

 if (k.Contains(Keys.S))
 force -= forward;

 verlet.Force += force * dt;
 }

 if (transform != null)
 {
 var theta = Vector3.Zero;

 if (k.Contains(Keys.A))
 theta.Z += Settings.TurnRate;

 if (k.Contains(Keys.D))
 theta.Z -= Settings.TurnRate;

 transform.Rotation += theta * dt;
 }

 if (k.Contains(Keys.Space))
 {
 var time = (float)args.GameTime.TotalGameTime.TotalSeconds - _rapidFireLast;

 if (time >= _rapidFireDelay)
 {
 Fire();
 _rapidFireLast = (float)args.GameTime.TotalGameTime.TotalSeconds;
 }
 }
 }
 

If your camera is mobile, give it its own `InputReceiver` and `Transform` component, attach a lambda or handler that implements whatever kind of control you want, and you're done.

This is kind of neat in that you can move the `InputReceiver` component with the navigation handler attached from the ship to an asteroid, or anything else for that matter, and fly that around instead. Or, by assigning a `Pov` component to anything else in your scene - an asteroid, street lamp, etc. - you can view your scene from that entity's perspective.

An `InputSystem` class that maintains an internal state for the keyboard, mouse, etc. `InputSystem` filters its internal entity collection to entities that have an `InputReceiver` component. In its `Update()` method, it iterates through that collection and calls the input handlers attached to each of those components in the same way that the rendering system draws each entity with a `Renderable` component.


**Particles**

This really depends on how you plan on interacting with the particles. If you just need a particle system that behaves like one object - say, a fireworks show that the player can't touch or hit - then I'd create a single entity, and a `ParticleRenderGroup` component that contains whatever information you need for the particles - decay, etc. - that isn't covered by your `Renderable` component. When rendering, the render system would see if an entity has the `RenderParticleGroup` attached and handle it accordingly.

If you need individual particles to participate in collision detection, respond to input, etc., but you just want to render them as a batch, I'd create a `Particle` component that contains that information on a per-particle basis. 

Then, either in your `MotionSystem` (or whatever your using that handles updating entity position, etc.) or in dedicated `ParticleSystem`, perform whatever processing is required for each particle per-frame. The `RenderSystem` would be responsible for building/batching and caching particle collections as they're created and destroyed, and render them as required.

One nice thing about this approach is that you don't have to have any special cases for collision, culling, etc. for particles; they code you write for every other kind of entity can still be used. 

**Conclusion**

If you're considering going cross-platform - not super-applicable to JavaScript - all of your platform-specific code (namely, rendering and input) is isolated into two systems. Your game logic remains in platform-agnositic classes (motion, collision, etc.) so you shouldn't have to touch them when porting.

I understand and agree with Sean's position that shoe-horning things into a pattern in order to strictly adhere to the pattern, rather than tweaking the pattern to fill the needs of your application, is bad. I just don't see anything in Input, Camera or Particles that requires that sort of treatment.