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

Support ResType on PropDefault annotation #174

Closed
wants to merge 10 commits into from
Closed

Support ResType on PropDefault annotation #174

wants to merge 10 commits into from

Conversation

pavlospt
Copy link
Contributor

@pavlospt pavlospt commented May 4, 2017

Initial work on adding support for ResType on @PropDefault ( #81 )

I went with the solution of having the Builder initializing the Props that have a default value marked as ResType, instead of passing down the ComponentContext which I tried to implement but it was introducing a quite huge change.

In order to reduce the review scope I have only added generation for resolveDimenSizeRes() and will add the rest before closing the PR, in order to have a naming and feature compliance agreement after the initial review. Also, I believe that after resolving the resource on a marked @PropDefault we should generate resource helper methods like we do for @Prop.

Let me know what you think!

/cc: @emilsjolander

P.S.: There is a big diff on the ComponentImplGenerator due to different Code Style, so If you could share the one you are using so that we could be aligned and reduce the diffs, would be great.

@emilsjolander
Copy link
Contributor

@pavlospt Thanks! I'll have a look today or tomorrow and give more detailed feedback. Before that could you please revert the style changes you made? We have our preferred formatting style and would rather not change it, also makes the PR harder to review.

@pavlospt
Copy link
Contributor Author

pavlospt commented May 4, 2017

@emilsjolander Yeap that's what I wrote on the ps, could you share your formatting style so that I can revert it? Because right now I don't see how I could that. Let me know if you have any ideas!

@pavlospt
Copy link
Contributor Author

pavlospt commented May 4, 2017

Code style issues are fixed!

@emilsjolander
Copy link
Contributor

We don't have a formal formatting style really. We should probably work on one though 👍 Just look at how the rest of the code in the files are formatted and try to follow the same style.

Copy link
Contributor

@emilsjolander emilsjolander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @IanChilds for annotation processor changes.

@@ -8,8 +8,10 @@

package com.facebook.samples.litho.lithography;

import android.graphics.drawable.Drawable;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems unused

import com.facebook.litho.Column;

import com.facebook.litho.annotations.ResType;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems unused


@LayoutSpec
public class PlaygroundComponentSpec {

@PropDefault(resType = ResType.DIMEN_SIZE)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you revert these changes? Good to see example used but we don't want to add a bunch of stuff to the playground.

@@ -0,0 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this file.

@@ -733,4 +768,21 @@ private static MethodSpec generateReleaseMethod(SpecModel specModel) {
.addStatement("$L.release(this)", BUILDER_POOL_FIELD)
.build();
}

private static String generateInitializer(PropDefaultModel propDefaultModel,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a line exceeds 100 we put all the parameters on the next line, including the first one 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emilsjolander Do you mean 100 chars? This line seems to be 78 chars including the leading space.

StringBuilder builtInitializer = new StringBuilder();

if (propDefaultModel.hasResType()) {
if (propDefaultModel.mResType == ResType.DIMEN_SIZE) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should handle all res types. See how this is done for the builder methods.

@pavlospt
Copy link
Contributor Author

pavlospt commented May 4, 2017

@emilsjolander thank you for the review, will try to fix them and finalize it.

@pavlospt
Copy link
Contributor Author

pavlospt commented May 4, 2017

@emilsjolander Fixed most of the review changes, one thing that is not clear though: in order to generate the initializers, should I create new variables?

What I mean is:

  • If someone marks a @PropDefault with a ResType then it would most probably require it to be an int in order to accept the R reference, which means that we would need to generate a variable for the resolved type of the ResType.

@pavlospt
Copy link
Contributor Author

pavlospt commented May 4, 2017

I had a discussion with @charbgr for possible approaches on the above issue:

The outcome was that we could add another key on @PropDefault called resId possibly and there the user would declare the resourceId that we would resolve.

That means that the user gets to declare the same type of variable as the @Prop annotated and we would not need to create other variables as mediators.

Example:

@PropDefault(resType = DRAWABLE, resId = R.mipmap.ic_launcher_round)
Drawable launcherImage;

@emilsjolander
Copy link
Contributor

Looks pretty good! thanks 👍 Could you please add tests for the added features?

@pavlospt
Copy link
Contributor Author

pavlospt commented May 9, 2017

@emilsjolander Sure thing, is there a specific directory for the Annotation Processor tests ?

@passy
Copy link
Member

passy commented May 9, 2017

Oh shoot, we're still working on getting the annotation processor tests open-sourced. There were some issues with Gradle and @IanChilds is working on fixing those.

@pavlospt
Copy link
Contributor Author

pavlospt commented May 9, 2017

@passy Hmmm, is there any way around this then ?

@IanChilds
Copy link
Contributor

We should have them available today or tomorrow :)

@pavlospt
Copy link
Contributor Author

@IanChilds Great!

@nscoding
Copy link

Any updates here? would be great to see this merged.

@pavlospt
Copy link
Contributor Author

@nscoding Did not find some free time to write the tests yet..Hopefully will be able to do so, in the following week!

@pavlospt
Copy link
Contributor Author

pavlospt commented Jun 1, 2017

@IanChilds can you please review the last commit? I had to use 12345 as a constant for the BuildGeneratorTest additions due to limitation annotation fields that need to be a constant expression. Inside a ComponentSpec it works like a charm because the R field reference is resolved into a constant ID in advance.

Copy link
Member

@passy passy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Just a nit about the .gitignore. I'll leave the annotation processor changes to @IanChilds to review. :)

.gitignore Outdated
@@ -18,4 +18,9 @@ docs/.bundle/
# Android Studio/IntelliJ
.idea
*.iml
.gradle/
lib/fb/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need those. :)
Can you revert that?

.gitignore Outdated
lib/fb/
lib/yoga/
lib/yogajni/
*/**.iml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should already be covered by the one above.

Copy link
Contributor

@IanChilds IanChilds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really awesome! Thanks for doing this!

for (PropDefaultModel propDefault : propDefaults) {
if (!propDefault.isResResolvable()) continue;

initResTypePropDefaultsSpec.addStatement("this.$L.$L = $L",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one param per line please :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

propsBuilderClassBuilder.addMethod(initMethodSpec.build());

if (initResTypePropDefaultsSpec != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why don't you just do everything at this point and then you don't have to do the null checks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@IanChilds can you explain this a little bit more? :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think what he's saying is if you move this up to the bottom of the if on line 221, you can drop the null check.

@@ -53,6 +96,8 @@ public int hashCode() {
int result = mType.hashCode();
result = 17 * result + mName.hashCode();
result = 31 * result + mModifiers.hashCode();
result = 31 * result + mResType.hashCode();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use a different number here and on the line below

@@ -97,6 +97,17 @@ public boolean hasDefault(ImmutableList<PropDefaultModel> propDefaults) {
return false;
}

public PropDefaultModel getDefault(ImmutableList<PropDefaultModel> propDefaults) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@IanChilds unused, I removed it. Thanks!

@lucasr
Copy link
Contributor

lucasr commented Jun 1, 2017

I'd update the docs for PropDefaults (https://fblitho.com/docs/props#prop-defaults) to cover this new feature :-)

@pavlospt
Copy link
Contributor Author

pavlospt commented Jun 1, 2017

@lucasr I can do this as well and include it in this PR :)

propsBuilderClassBuilder.addMethod(initMethodSpec.build());

if (initResTypePropDefaultsSpec != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think what he's saying is if you move this up to the bottom of the if on line 221, you can drop the null check.

@@ -199,8 +216,26 @@ static TypeSpecDataHolder generateBuilder(SpecModel specModel) {
initMethodSpec.addStatement("mRequired.clear()");
}

MethodSpec.Builder initResTypePropDefaultsSpec = null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move into the if statement below

import com.facebook.yoga.YogaAlign;

import com.facebook.yoga.YogaFlexDirection;
import com.facebook.litho.widget.Text;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: can you undo this change (it's nicer when we keep them alphabetized).

@@ -53,6 +96,8 @@ public int hashCode() {
int result = mType.hashCode();
result = 17 * result + mName.hashCode();
result = 31 * result + mModifiers.hashCode();
result = 43 * result + mResType.hashCode();
result = 65 * result + mResId;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick - for consistency, can you replace 65 with 47 or 53 or 59 or 61 to keep it as prime numbers?

@pavlospt
Copy link
Contributor Author

pavlospt commented Jun 2, 2017

@ahmedre Updated to reflect review requests. Can you check again :) ?

@ahmedre
Copy link
Contributor

ahmedre commented Jun 2, 2017

@pavlospt may you also update props.md with these changes? btw, thanks for doing this!

lgtm otherwise, but will leave the remaining review checks to the Litho core team

@pavlospt
Copy link
Contributor Author

pavlospt commented Jun 2, 2017

@ahmedre Done :)

@facebook-github-bot
Copy link
Contributor

@IanChilds has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

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

Successfully merging this pull request may close these issues.

None yet

8 participants