seeder
seeder copied to clipboard
MartinKavik
Components
I really like how the seed framework is starting to shape up and as you @MartinKavik are creating a cli tool for it, I decide to try and suggest something:
I quite love at the moment in Ember.js how components work and how code can be organized. Ember.js has a router, models, controllers, services, templates and components. Usually a controller or a component is paired with a template. If you then use an addon like ember-css-modules you can also have namespaced CSS (or SASS/LESS) associated with that component.
The main advantage of this structure is that you can create small independent modules that are self contained in the same folder. I would suggest a similar structure for components here:
|-- components
|-- some-component-name
|-- component.rs
|-- view.rs
|-- styles.sass
Do you think something like this would be doable or even a good idea?
I know this is kind of structure is not exclusive on ember.js but it really does wonders to organize your code base.
Hi @cascalheira I quite agree with your proposal. I have used that structure in React land before coming to Rust/Seed.
Have you looked at Seed's pages examples? These examples implement a similar structure, that IMO is overly verbose (reminds me of Java/Spring structure), that's one Rust standard. There is another that eliminates the extra directories used in the pages examples. I much prefer the simpler structure you outlined, even if it must be littered with empty mod.rs files. At least in that case everything is contained within the component directory.
In the end this is @MartinKavik's decision, I'm just adding my opinion.
Hello @gihrig I agree but I've seen it done both ways: I think we either can have it like some frameworks do, and then there is an additional build step where files are concatenated, namespaced, etc. and we don't need to add mod.rs and probably can reduce a lot on boilerplate but this has some downsides, amongst them the fact that IDEs and editors will not like it, code completion will not work properly and with a lot of "magic" happening some odd and hard to debug bugs might appear . The other option is to just have all the boilerplate to import everything, add mod.rs files, etc.
To be honest both of those options have big upsides and big downsides so I don't really have an opinion on what should be done and indeed I think this should be @MartinKavik decision.
If the project goes the way of having the boilerplate explicitly in the code, that can be heavily mitigated with CLI generators that just create the basic structure of a component.
Scoped CSS
- @rebo will release alpha version of CSS/Less/SASS library for Seed:
- The most design discussions are on chat - write him on
#develor#supportchannel if you want to know more. - It's Rust typed, but you can use raw CSS in your app code.
- Under the hood it modifies styles in header so you get basically namespaced/scoped styles for free.
- The most design discussions are on chat - write him on
- Another solution is to use custom elements and shadow-dom but we've decided to not go this way for Seed's core / libraries. However nothing can stop you to write and use individual web components and Seed will support Rust web components in the future.
Related issues:
- https://github.com/seed-rs/seed/issues/413
- https://github.com/seed-rs/seed/issues/336
Components
Current Seed app architecture is the pure TEA (The Elm architecture) - boilerplate is a trade-off for explicit behavior, simple patterns and single source of truth. It's the reason why pages (and other examples have some boilerplate).
However we understand that TEA is good for custom/business logic but it's too annoying when you want to write non-business or generic components or Seed library. That's why Hooks are in development - tutorial exists (write @rebo, I don't remember the link and there were some minor stylesheet problems) and we were designing it with @rebo for relatively long time to make it as simple and powerful as possible. However hooks still needs nighly Rust, but it should change during next months and then it will be integrated into Seed and allows you to write real components with internal state.
Related issue: https://github.com/seed-rs/seed/issues/339
So... I want to take inspiration mainly from elm-spa as the first step - they had to resolve generators for apps with TEA. And once new styles and hooks are integrated into Seed, I'll write support for them to mitigate boilerplate.
@cascalheira While I prefer the least boiler plate possible I would strongly advocate against any "Magic" that breaks IDEs.
Whether to use the (newer?) "file + directory" or the (older?) "mod.rs within directory" pattern is a matter of personal opinion, I suppose. At this stage it may not even be too difficult to support both, based on a config option.
@MartinKavik Sounds good. I also understand that Seed is in a new web framework and what I am suggesting here will probably not be important for a long time. I was just suggesting that for consideration as it can be relevant in the future. TEA sounds good for now of course!
@gihrig Yes, that kind of "magic" is awful.
I would strongly advocate against any "Magic" that breaks IDEs.
We tries to take into account all possible problems during API / logic designing - see e.g. this comment for example of design process.